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Abstract 


In  2010,  the  Shared  Spectrum  Company  showed  in  a  survey  of  Radio  Frequency  (RF) 
bands  that  underutilization  of  spectrum  has  resulted  from  current  frequency  management 
practices.  Traditional  frequency  allocation  allows  large  bands  of  licensed  spectrum  to 
remain  vacant  even  under  current  high  demands.  Cognitive  radio’s  (CR)  use  of  Dynamic 
Spectrum  Access  (DSA)  enables  better  spectrum  management  by  allowing  usage  in  times 
of  spectrum  inactivity.  This  research  presents  the  CR  problem  of  rendezvous  for  fast 
Frequency  Hopping  Spread  Spectrum  (FHSS)  networks,  and  examines  protocols  for 
disseminating  RF  environment  information  to  coordinate  spectrum  usage.  First,  Gold’s 
algorithm  is  investigated  as  a  rendezvous  protocol  for  networks  utilizing  fast  frequency 
hopping.  A  hardware  implementation  of  Gold’s  algorithm  on  a  Virtex-5  Field 
Programmable  Gate  Array  (FPGA)  is  constructed  to  determine  the  resource  requirements 
and  timing  limitations  for  use  in  a  CR.  The  resulting  design  proves  functionality  of  the 
algorithm,  and  demonstrates  a  decrease  in  time-to-rendezvous  over  current  methods.  Once 
a  CR  network  is  formed,  it  must  understand  the  changing  environment  in  order  to  better 
utilize  the  available  spectrum.  This  research  addresses  the  costs  a  network  incurs  to 
coordinate  such  environment  data.  Three  exchange  protocols  are  introduced  and  evaluated 
via  simulation  to  determine  the  best  technique  based  on  network  size.  The  resulting 
comparison  found  that  smaller  networks  function  best  with  polled  or  time-division  based 
protocols  where  radios  always  share  their  environment  information.  Farger  networks,  on 
the  other  hand,  function  best  when  a  dispute-based  exchange  protocol  was  utilized.  These 
studies  together  conclude  that  the  selection  of  a  rendezvous  algorithm  or  a  protocol  for  the 
exchange  of  environment  data  in  a  CR  network  are  determined  by  the  characteristics  of 
the  network,  and  therefore  their  selection  requires  a  cognitive  decision. 
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ESTIMATION  AND  COORDINATION  OF  SEQUENCE  PATTERNS  FOR 
FREQUENCY  HOPPING  DYNAMIC  SPECTRUM  ACCESS  NETWORKS 


I.  Introduction 

Continuing  development  of  wireless  systems  causes  increasing  stress  on  the  available 
spectrum  resources  in  the  United  States  and  other  countries  throughout  the  world. 
The  National  Telecommunications  and  Information  Administration  (NTIA)  and  the 
Federal  Communications  Commission  (FCC)  control  the  spectrum  availability  and  usage 
in  the  United  States.  NTIA  controls  frequencies  assigned  to  federal  agencies  while  the 
FCC  administers  commercial  and  state  use.  In  November  2010  the  FCC  released  a  notice 
of  inquiry  focusing  on  dynamic  spectrum  access  technologies  to  enable  more  efficient 
utilization  of  the  limited  spectrum.  The  notice  presented  several  federal  and  non-federal 
programs  that  investigate  possible  solutions  to  alleviate  the  spectrum.  One  such 
technology  is  referred  to  as  Cognitive  Radio  (CR)  [10]. 

The  NTIA  in  [25]  defines  a  CR  system  as  “a  radiocommunication  system  that  is 
aware  of  its  environment  and  internal  state  and  can  make  decisions  about,  and  adjust,  its 
operating  characteristics  based  on  information  and  predefined  objectives.”[25]  CR  is  the 
enabling  technology  for  Dynamic  Spectrum  Access  (DSA)  which  is  the  operation  of 
changing  spectrum  usage  based  upon  the  state  of  the  Radio  Frequency  (RF)  environment. 
DSA  is  currently  a  topic  of  focus  for  researching  bodies  around  the  world  to  include  the 
Air  Force  Institute  of  Technology  (AFIT).  Research  at  AFIT  investigates  the  use  of  DSA 
for  both  civilian  and  military  applications  while  advancing  technology  in  the  area  of  radio 
communication. 
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1.1  Motivation 


The  Air  Force  relies  heavily  on  wireless  communication  systems.  Communication 
between  command  centers,  personnel,  and  other  military  platforms  is  vital  for  successful 
operations.  Twelve  core  functions  comprise  the  US  Air  Force:  Nuclear  Deterrence 
Operations,  Special  Operations,  Air  Superiority,  Global  Integrated  ISR,  Space  Superiority, 
Command  and  Control,  Cyberspace  Superiority,  Personnel  Recovery,  Global  Precision 
Attack,  Building  Partnerships,  Rapid  Global  Mobility  and  Agile  Combat  Support  [31]. 
Each  of  these  functions  greatly  depend  on  continuous  and  reliable  communication.  As 
such,  the  Air  Force  has  outlined  the  current  state  of  capabilities,  assessed  projected 
challenges,  and  presented  a  plan  to  address  problems.  This  Air  Force  report  discusses 
“Frequency  Agile  Spectrum  Utilization”,  a  sub-topic  of  DSA,  as  a  potential  capability 
area  [3]. 

Military  radio  requirements  vary  widely  from  commercial  requirements  due  the 
range  of  operational  environments  and  higher  reliability  requirements.  For  instance, 
Frequency  Hopping  Spread  Spectrum  (FHSS),  used  in  many  military  systems,  is  a  method 
of  transmission  not  commonly  used  by  commercial  radio  systems  due  to  the  lower  data 
rates  they  provide.  This  addition  of  FHSS  to  the  problem  space  brings  separate  challenges 
to  the  study  of  CR  for  military  use. 

1.2  Problem  Statement 

The  objective  of  this  research  is  to  investigate  Gold’s  algorithm  as  a  rendezvous 
method  for  FHSS  radio  systems  utilizing  DSA,  and  to  evaluate  the  network  performance 
losses  caused  by  exchanging  radio  environment  data.  Explored  separately,  research  into 
these  topics  areas  expand  upon  previous  AFIT  cognitive  radio  research  designed  to 
construct  and  evaluate  a  prototype  CR. 

For  any  network  to  begin  functioning,  the  network  itself  must  be  established. 
Rendezvous  is  the  process  of  establishing  a  communication  link  between  two  or  more 
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radios  or  radio  networks.  Current  research  on  the  rendezvous  problem  ignores  the 
functionality  of  FHSS  within  a  DSA  environment.  The  research  in  this  document 
addresses  this  missing  consideration.  It  also  investigates  the  hardware  specifications  and 
timing  limitations  for  implementing  a  unique  rendezvous  algorithm  for  FHSS  on  an 
Field-Programmable  Gate  Array  (FPGA)  based  development  platform. 

In  addition  to  establishing  a  network  connection,  radios  must  coordinate  a  common 
picture  of  the  environment.  The  exchange  of  environment  data  requires  additional  data 
transfers  as  overhead  which  reduces  the  overall  performance  of  a  network.  Network 
performance  describes  the  transfer  characteristics  of  non-control  data  to  include 
throughput,  delay,  and  data  drop  rates.  The  exchange  of  environment  data  occurs  when 
needed  or  on  a  set  schedule.  This  research  investigates  the  overhead  cost  of  performing  an 
exchange  under  different  conditions.  A  lack  of  research  into  exchange  protocol  effects 
suggest  that  no  standard  metrics  exist  to  identify  the  efficiency  of  a  protocol,  nor  do  any 
test  data  sets  exist  to  represent  real-world  environments  for  testing  of  a  protocol. 

The  specific  goals  of  this  research  are  to: 

•  demonstrate  that  Gold’s  algorithm  allows  for  successful  rendezvous  on  a  FHSS 
radio  network  without  dwell  time  or  common  control  channel  requirements. 

•  present  resource  requirements  and  timing  limitations  for  an  FPGA  implementation 
of  Gold’s  algorithm. 

•  analytically  show  that  the  above  algorithm  is  capable  of  operating  within  the  DSA 
paradigm. 

•  evaluate  the  performance  of  three  possible  exchange  protocols  for  transferring  radio 
environment  data  on  a  multi-nodal  radio  network  via  wireless  network  simulation. 
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1.3  Research  Contributions 


This  research  provides  two  distinct  contributions  to  the  study  of  DSA,  and  therefore 
the  field  of  CR.  First,  it  establishes  Gold’s  algorithm  as  a  valid  rendezvous  method  for 
Frequency  Hopping  DSA  networks.  Compared  to  traditional  rendezvous  methods  such  as 
Code-of-the-Day  (COD),  Gold’s  algorithm  reduces  joining  time  when  higher  hop  rates  are 
required.  Additionally,  this  research  offers  the  first  FPGA  hardware  implementation  of 
Gold’s  algorithm  providing  timing  and  resource  requirements  for  radio  designers. 

Second,  this  research  demonstrates  the  impact  to  network  performance  for  three 
exchange  protocols  when  radio  channel  availability  data  must  be  exchanged  as  part  of 
DSA  operations.  Examination  of  metrics  such  as  data  throughput,  delay,  and  data  drop 
rates  provide  an  estimation  of  network  performance  with  varying  network  size  under 
different  network  non-control  traffic  workloads.  A  comparison  of  these  metrics  and  their 
correlations  determine  the  exchange  protocol  that  minimizes  the  overhead  costs  to  the 
network. 

Two  OPNET  nodal  models  were  developed  to  compare  the  exchange  protocols. 
Utilization  of  these  models  provide  future  researchers  with  advanced  capabilities  not 
currently  available.  The  first  model  expands  the  features  of  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  802.11b  OPNET  wireless  model  to  incorporate  the 
transmission  technique  of  FHSS.  OPNET’s  model  provides  frequency  hopping  as  a 
function  option,  but  the  feature  was  never  implemented  in  the  model.  The  improved  model 
is  currently  restricted  to  slow-hopping  operations.  The  second  model  modifies  the  Point 
Coordination  Function  (PCF)  of  IEEE  802. 1  lb  within  the  Medium  Access  Control  (MAC) 
process  model.  This  modification  allows  PCF  operation  without  the  need  of  a  dedicated 
access  point,  and  leverages  the  PCF  operation  for  transfer  of  radio  environment  data  only. 
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1.4  Thesis  Organization  and  Overview 

Chapter  2  examines  related  work  on  topics  within  cognitive  radio,  and  provides 
background  information.  It  begins  with  an  overview  of  cognitive  radio  and  spectrum 
allocation  terminology.  The  chapter  continues  by  providing  an  overview  of  frequency 
hopping  spread  spectrum,  then  explores  the  problems  of  rendezvous  and  environment 
mapping. 

Chapter  3  presents  the  methodology  for  the  research  experiments  on  both  Gold’s 
algorithm  and  the  network  overhead  cost  simulations.  First,  it  discusses  the  development 
and  experimentation  of  the  custom  Intellectual  Property  (IP)  core  implementation  of 
Gold’s  algorithm  to  determine  system  physical  and  timing  specifications.  Secondly,  the 
chapter  describes  three  potential  exchange  protocols  for  transferring  environmental  data, 
and  the  methodology  for  testing  these  protocols  for  network  performance  using  wireless 
network  simulation.  Finally,  the  analysis  approach  and  hypothesis  of  the  experiments  is 
disclosed. 

Chapter  4  presents  and  analyzes  the  results  for  the  implementation  of  Gold’s 
algorithm  and  network  simulation  experiments.  The  analysis  for  Gold’s  algorithm 
considers  timing  limitations,  resource  requirements,  and  expected  rendezvous 
performance.  Additionally,  a  discussion  on  translating  hop  sequences  to  usable  channels 
in  a  DSA  environment  is  presented.  Thereafter,  the  chapter  examines  the  network 
simulation  results,  and  presents  their  impact  on  performance. 

Chapter  5  summarizes  the  conclusions  of  this  research,  discussing  its  contributions, 
and  providing  suggestions  for  future  work.  Appendices  containing  experimental  results,  a 
detailed  explanation  of  Gold’s  algorithm,  an  example  of  Gold’s  algorithm,  and  Very  High 
Speed  Integrated  Circuit  Hardware  Description  Language  (VHDL)  code  are  attached  at 
the  end  of  the  document. 
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II.  Related  Work 


Dr.  Joseph  Mitola  first  introduced  cognitive  radio  in  1998  as  part  of  his  doctoral 
dissertation  [23]  [24].  This  dissertation  defined  the  early  concepts  of  cognitive 
radio  in  terms  of  feature  requirements  and  a  possible  architecture.  As  part  of  early 
development,  Mitola  attempted  to  classify  characteristics  of  radio  cognition  into  the  nine 
levels  shown  in  Table  2.1. 


Table  2.1:  Mitola’s  Characteristics  of  Radio  Cognition  Tasks  [24] 


Level 

Capability 

Task  Characteristics 

0 

Pre-programmed 

The  radio  has  no  model-based  reasoning  capability 

1 

Goal-driven 

Goal-driven  choice  of  RF  band,  air  interface,  and  protocol 

2 

Context  Awareness 

Infers  external  communications  context  (minimum  user  involvement) 

3 

Radio  Aware 

Flexible  reasoning  about  internal  and  network  architectures 

4 

Capable  of  Planning 

Reasons  over  goals  as  a  function  of  time,  space,  and  context 

5 

Conducts  Negotiations 

Expresses  arguments  for  plans/  alternatives  to  user,  peers,  networks 

6 

Learns  Fluents 

Autonomously  determines  the  structure  of  the  environment 

7 

Adapts  Plans 

Autonomously  modifies  plans  as  learned  fluents  change 

8 

Adapts  Protocols 

Autonomously  proposes  and  negotiates  new  protocols 

Concept  development  using  these  levels  progressed  through  the  exceptional  efforts  of 
researchers  around  the  world.  Vanu  Bose  with  an  alternate  view  of  cognition  described  his 
vision  of  a  fully  programmable  radio  to  improve  spectrum  usage  as  ’’dynamically  adapting 
the  physical  layer  of  the  network  to  best  meet  the  current  environmental  conditions, 
network  traffic  constraints  and  application  requirements,  rather  than  a  lowest  common 
denominator  service  that  must  accommodate  the  worst  case.”[6]  No  matter  the  vision  of 
cognitive  radio,  common  themes  arose  in  areas  of  interest.  The  research  presented  in  this 
paper  focuses  on  the  concept  of  DSA  to  utilize  the  spectrum  more  efficiently.  Level  6  best 
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represents  DSA  in  Mitola’s  characteristics.  Putting  DSA  and  CR  into  use  first  requires  an 
understanding  of  current  spectrum  management  practices. 

The  FCC  manages  and  regulates  all  domestic  non-federal  spectrum  under  Title  47 
US  Code  301.  The  FCC  currently  divides  the  spectrum  into  two  categories,  Unlicensed 
Spectrum  and  Licensed  Spectrum  for  Commercial  Services.  Unlicensed  Spectrum  are 
frequencies  designated  as  ’’unlicensed”  or  ’’licensed-exempt”  where  any  user  can  operate 
devices  without  the  need  of  an  FCC  license,  but  must  use  certified  radio  equipment  that 
complies  with  FCC  requirements.  Since  no  license  is  required,  operation  in  this  spectrum 
typically  involves  dealing  with  levels  of  interference.  Frequencies  such  as  in  the 
Industrial,  Scientific  and  Medical  (ISM)  radio  bands  and  the  Unlicensed  National 
Information  Infrastructure  (U-NII)  radio  band  fall  under  the  unlicensed  category  [11]. 
Licensed  Spectrum  designated  for  commercial  services  allow  exclusive  ownership  or  use 
of  particular  frequencies.  Locality  of  transmission  also  affects  the  restricted  use  of 
licensed  spectrum. 

As  the  controlling  authority,  FCC  reports  on  a  constant  basis  the  allocations  of 
spectrum  to  different  users.  Figure  2.1  show  a  summary  break  down  of  the  300-3000  MHz 
frequency  span.  The  assignment  of  spectrum  using  this  two  category  system  does  not 
ensure  optimal  use  of  that  spectrum;  therefore,  to  make  any  improvements  the  current 
usage  must  be  understood. 


Figure  2.1:  Division  of  Spectrum  Between  Government  and  Non-Government  [38] 
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Starting  in  2004,  the  Shared  Spectrum  Company  has  collected  spectrum  data  in 
several  US  cities  to  investigate  current  usage  [20,  21,  32].  These  collection  studies  showed 
many  of  the  channels  reserved  as  licensed  spectrum  are  underutilized.  Figure  2.2  shows 
the  reported  the  usage  over  time  of  2.4  GHz  to  2.5  GHz  in  the  study  of  Vienna,  VA.  Under 
utilization  of  the  spectrum  is  a  large  catalyst  for  the  development  of  DSA. 

McLean  et  al.  attempted  to  highlight  the  functions  needed  in  implement  a  working 
DSA  radio  system  [22].  Specifically,  they  present  a  list  of  functions  required  for  the 
cognitive  process  to  maintain  communication.  Figure  2.3  graphically  represents  these 
functions. 


SSC  Rooflop  Antenna  Collection  -  Start;  01/Sep/2009. 18:12:48  Slop:  05/Sep/2009.  09:04:56 

Max  Hold 


1 - 1 - T 


ISM 


I - 1 - 1 - 1 - r 


-40 
-60 
-80  - 
-100  - 


-120 


y-pcs 


2390  2400 


U&rfall  plo??power2re  corded  whe^Setecllo^fftesholil^exceeleT  2490  2500 


2390  2400  2410  2420  2430  2440  2450  2460  2470  2480  2490  2500 


Frequency  (MHz) 

Figure  2.2:  2.4GHz  to  2.5GHz  usage  Vienna,  VA  [32] 
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Figure  2.3:  Cognitive  radio  system  function  diagram  [22] 
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2.1  Frequency  Hopping 

The  term  frequency  hopping  exists  throughout  cognitive  radio  research.  This  section 
attempts  to  categorize  the  different  types  of  frequency  hopping  in  order  to  differentiate  the 
DSA  scenarios. 

Traditional  frequency  hopping  describes  any  radio  mode  of  operation  where  the 
communication  channel  changes  over  time.  For  example,  a  radio  may  operate  on 
Channel  #1,  and  increment  its  channel  by  one  channel  every  minute.  The  act  of 
automatically  changing  frequencies  according  to  a  sequence  or  algorithm  defines 
frequency  hopping;  however,  distinguishing  the  amount  of  information  that  can  be 
exchanged  while  occupying  a  single  frequency  divides  frequency  hopping  into  categories. 
Radio  communications  developers  use  two  common  categories,  Fast  Frequency 
Hopping  (FFH)  and  Slow  Frequency  Hopping  (SFH)  [26] . 

In  FFH,  the  hop  rate  (rate  of  frequency  change)  exceeds  the  symbol  rate  causing  a 
single  data  symbol  to  be  cast  over  multiple  frequency  channels  during  transmission. 
Although  traditionally  resulting  in  lower  data  transfer  rates,  FFH  provides  a  level  of  bit 
error  correction  based  on  the  ability  to  compare  a  data  symbol  over  the  multiple 
frequencies.  For  instance,  if  a  data  symbol  is  transmitted  over  five  frequencies  then  the 
received  majority  is  likely  to  represents  the  true  value  that  was  transmitted. 

A  system  is  considered  to  be  SFH  if  the  hop  rate  is  less  than  the  data  symbol  rate. 
Most  commercial  radios  use  this  type  of  frequency  hopping  for  use  in  IEEE  802.1 1  for 
Wireless  Local  Area  Networks  and  IEEE  802.15  for  Bluetooth  technologies.  The 
definition  of  SFH  contains  an  ambiguity  when  classifying  a  radio  transmission  by  the 
quantity  of  data  transferred.  The  definition  covers  a  radio  capable  of  transmitting  as  little 
as  a  single  data  symbol  or  more  than  an  entire  packet  before  changing  frequencies.  As 
such,  a  new  division  of  SFH  into  more  specific  categories  is  needed.  Distinguishing  the 
ability  to  establish  reliable  communication  channel,  typically  a  resulting  from  a 
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“handshake”  protocol,  produces  a  possible  division  point.  This  document  provides 
terminology  to  identify  this  division. 

Let  full-packet  slow  frequency  hopping  (FPSFH)  define  the  case  when  all  needed 
traffic  to  establish  a  connection  can  be  transferred  during  a  single  time  slot,  and  let 
sub-packet  slow  frequency  hopping  (SPSFH)  define  the  case  when  the  exchange  can  not 
occur  during  a  single  time  slot.  The  definitions  of  FFH,  FPSFH,  and  SPSFH  establish  an 
additional  factor  for  determining  the  applicability  of  different  DSA  routing  and 
rendezvous  protocols. 

2.2  Problem  of  Rendezvous 

Users  within  a  CR  network  detect  the  presence  of  other  users  to  establish 
communications  links  thereby  allowing  for  information  exchanges  to  occur.  The  process 
of  two  or  more  radios  or  radio  networks  establishing  a  communication  link  defines 
rendezvous.  Rendezvous  requires  that  the  users  occupy  the  same  channel  at  the  same  time 
to  establish  a  link.  This  fundamental  task  becomes  increasingly  more  difficult  as  the 
complexity  of  the  communication  medium  and  communication  protocols  change.  For 
instance,  if  a  radio  user  (Radio  A)  can  only  operate  on  a  single  channel,  then  any  other 
radio  user  (Radio  B)  can  easily  perform  a  rendezvous  by  using  the  same  channel. 

As  Radio  A  increases  the  number  of  available  channels  it  operates  on,  Radio  B’s  task 
of  finding  the  correct  channel  increases  too.  Let  Radio  A  select  and  remain  static  on  one 
of  its  N  available  channels.  Radio  B  must,  at  most,  search  each  of  the  N  channels  before 
rendezvous  occurs.  Next,  let  Radio  A  change  its  operating  channel  according  to  a  set 
algorithm  or  sequence.  Radio  B  must  determine  a  way  to  rendezvous  with  increased 
difficulty.  This  problem  becomes  non-trivial.  Further  adding  cognitive  abilities  to  a  radio 
brings  the  dynamic  element  of  a  changing  number  of  available  frequencies  for  each  user. 

This  is  the  essence  of  the  rendezvous  problem  for  CR  networks.  For  evaluation, 
metrics  provide  the  ability  to  compare  different  rendezvous  algorithms  against  one 
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another.  One  important  metric  is  Time-to-Rendezvous  (TTR),  which  is  defined  as  the 
number  of  time  slots  required  for  a  rendezvous  to  occur.  However,  since  the  TTR  depends 
on  the  specific  channel  order  that  the  radios  follows,  the  maximum  TTR  (MTTR)  metric  is 
commonly  used.  MTTR  is  the  TTR  for  the  worst  case  scenario  when  applying  a 
rendezvous  algorithm.  The  problem  space  for  rendezvous  within  CR  networks  is  vast,  and 
many  algorithms  have  already  been  created  to  address  differing  applications. 

2.2.1  Previous  Algorithms. 

Rendezvous  algorithms  can  be  categorized  by  the  assumptions  required  for 
operation,  and  by  the  extent  which  the  algorithm’s  effectiveness  can  be  applied.  Liu  et  al. 
suggested  a  taxonomy  for  subdividing  channel  hopping  rendezvous  algorithms  based  on 
the  target  environment  [18].  Figure  2.4  displays  a  visual  representation  of  this  taxonomy. 


Figure  2.4:  Taxonomy  of  rendezvous  algorithms  [18] 
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The  top  level  of  the  categorization  splits  by  identifying  algorithms  based  on  the 
topography  of  the  system.  These  two  systems  are  centralized  and  decentralized.  In  a 
centralized  system,  a  user  requires  a  centralized  controller  (server)  to  assist  users  in  the 
rendezvous  process.  A  decentralized  system  does  not  require  server  assistance  to 
rendezvous.  Both  types  of  systems  may  utilize  a  Common  Control  Channel  (CCC).  The 
inherent  limitations  of  a  centralized  system  led  research  to  focus  on  decentralized  systems. 
The  failure  of  a  server  resulting  in  the  crippling  the  entire  network  is  one  such  limitation. 
This  research  focuses  on  decentralized  systems. 

Using  a  dedicated  CCC  is  the  simplest  way  to  coordinate  rendezvous.  The  CCC 
approach  divides  time  into  two  intervals:  control  interval  and  data  interval.  During  the 
control  interval,  users  coordinate  and  select  an  available  channel  for  data  transfer. 

Figure  2.5  illustrates  such  an  exchange  using  a  CCC.  The  CCC  is  assumed  to  be  reachable 
by  every  CR  (global)  or  to  a  select  group  of  CRs  (local),  normally  determined  by  a 
clustering  algorithm  [42]. 
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Figure  2.5:  Common  Control  Channel  coordination  [15] 


The  use  of  a  CCC  causes  inherent  problems  such  as  the  coordination  of  the  control 
channel  itself,  the  availability  of  the  channel,  and  its  susceptibility  to  malicious 
interference.  The  lack  of  a  CCC  is  typically  addressed  as  a  more  complicated  problem 
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known  as  blind  rendezvous.  When  no  CCC  is  needed,  algorithms  are  further  divided  by 
the  need  for  time-synchronization  on  the  systems  to  communicate.  Lastly,  a  division 
occurs  between  the  environment  models  in  which  the  algorithm  applies.  A  symmetric 
model  describes  the  situation  where  each  CR  has  the  same  available  channels.  The 
asymmetric  model  represents  all  other  cases. 

Research  toward  the  development  of  CR  introduced  a  number  of  algorithms.  In  an 
attempt  to  remain  robust,  research  focused  on  decentralized  systems  for  rendezvous 
algorithms.  A  successful  channel-hopping  (CH)  rendezvous  protocol  meets  three  basic 
requirements:  [5,  42] 

1 .  Every  pair  of  nodes  should  have  a  chance  to  meet  every  other  node  periodically 
within  a  bounded  interval. 

2.  All  nodes  should  be  able  to  rendezvous  on  every  channel  it  is  capable  of  using  for 
communication. 

3.  All  channels  should  have  the  same  probability  to  be  utilized  as  the  control  channel. 

More  complicated  scenarios  were  generated  as  algorithm  development  progressed.  A 
scenario  driven  view  of  many  of  the  known  rendezvous  algorithms  provides  better 
understanding  of  the  algorithms  and  their  functions.  To  establish  different  scenarios,  a  set 
of  global  assumptions  must  be  made  about  the  network.  First,  any  radio  node  being 
considered  as  part  of  the  system  must  share  at  least  one  channel  with  the  other  radios  in 
the  system.  This  means  the  operational  ranges  of  the  radio  in  the  network  must  overlap. 
Second,  at  least  one  channel  must  be  open  within  the  overlapping  channels  for 
communication  exchange  to  occur.  Third,  radios  must  be  capable  of  exchanging 
information  once  co-existence  on  a  channel  occurs. 

The  simplest  scenario  within  rendezvous  is  communication  between  only  two  radios 
operating  under  the  symmetric  environment  model  (i.e.  all  nodes  have  the  same  open 
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channels).  The  Random  Algorithm  (RA),  the  first  algorithm  investigated,  operated  by 
selecting  at  random  an  open  channel  from  a  list.  Random  algorithms  cannot  guarantee  the 
rendezvous  of  nodes  in  a  bounded  time;  however,  RA  is  considered  the  baseline  from 
which  other  algorithms  developed. 

Sequence  based  algorithm  design  is  one  method  to  ensure  rendezvous.  In  [7], 

DaSilva  &  Guerreiro  proposed  Sequence-based  Rendezvous  (SeqR)  capable  of  linking 
two  radios  with  an  MTTR  of  M(M  +  1)  time  slots.  The  algorithm  does  not  require 
time-synchronization,  but  is  limited  to  the  symmetric  model. 

A  second  scenario  exists  by  expanding  the  two  node  scenario  to  include  the 
asymmetric  model  conditions.  Sequence  rotation  algorithms  such  as  Modular  Clock  and 
Modified  Modular  Clock  (MMC)  displayed  the  ability  to  work  for  both  the  asymmetric 
and  symmetric  models  [35].  These  algorithms  are  based  on  a  prime  modulus  function  and 
a  randomly  selected  hop  distance.  The  algorithms  showed  a  bounded  MTTR  as  long  as 
both  the  rate  and  prime  number  are  not  selected  as  the  same  value  for  more  than  one  node. 
A  separate  effort  demonstrated  applicability  of  these  algorithms  via  hardware 
implementation  on  the  GNU  radio  test  bed  [30].  It  also  presented  a  comparison  of  MMC, 
RA,  and  a  modified  MMC. 

Expanding  off  the  modular  clock  design,  [17]  proposed  two  ring-walk  algorithms. 
This  algorithm  added  a  separate  time  component  where  each  node  may  or  may  not 
perform  a  frequency  change.  The  ability  to  hold  on  a  channel  eliminated  the  limitation 
that  the  modular  clock  presented.  As  such,  the  ring-walk  algorithm  guaranteed  rendezvous 
of  two  users  in  a  time  slot  without  time-synchronization  on  both  symmetric  and 
asymmetric  models.  More  than  two  radios  may  visit  the  same  operating  channel  in  the 
above  scenarios,  but  the  design  of  the  algorithms  did  not  ensure  this  event  to  occur. 

Bian  et  al.  in  [5]  demonstrated  Quorum-based  channel  hopping  (QCH).  Novel  to  this 
algorithm  class  was  the  insurance  that  rendezvous  occurred  on  multiple  channels  within  a 
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single  sequence  period.  This  meant  that  several  chances  to  rendezvous  occur.  The  paper 
presented  a  comparison  between  QCH,  RA,  and  SeqR  to  demonstrate  the  multiple 
overlapping  channels  effect.  Using  the  QCH  approach,  Bain  et.  al  introduced  three 
distinct  variations:  M-QCH  to  minimize  MTTR,  L-QCH  to  minimizes  the  load  on  the 
channels,  and  A-QCH  to  handle  asynchronous  operations. 

The  usefulness  of  only  two  radios  communicating  quickly  loses  its  practicality  when 
developing  complex  scenarios.  This  caused  researchers  to  expand  into  two  different 
multi-node  scenarios,  organized  hop  and  multiple  pairing.  Lin  et  al.  proposed  the  jump 
stay  (JS)  algorithm  which  functions  by  dividing  the  hop  sequence  into  two  parts,  an  active 
jump  pattern  and  a  passive  stay  pattern.  The  selection  of  jump  moves  are  based  on  a 
random  step  distance  and  starting  point  (through  a  modulus  function).  During  stay  period 
a  single  channel  is  held.  The  sequence  created  is  similar  to  the  ring-walk  algorithm; 
however,  the  JS  algorithm  extended  to  multi-user  scenarios  where  more  than  two  nodes 
can  meet  on  the  same  channel.  As  such,  [16]  presented  the  organized  hop  method  by 
which  many  users  can  force  synchronization  of  patterns  when  nodes  meet.  Two  nodes  will 
adopt  the  same  sequence  when  they  rendezvous  and  hop  as  an  organized  unit.  As  more 
rendezvous  occur  the  organized  pack  grows.  Since  the  JS  algorithm  is  bounded  it  ensured 
that  all  nodes  eventually  exist  on  the  same  pattern  [16].  This  method  expands  to  almost  all 
previous  algorithms.  In  a  comparison  of  known  algorithms,  JS  had  the  best  overall 
performance  among  single  pair  rendezvous  algorithms  covering  both  symmetric  and 
asymmetric  models  according  to  [18]. 

Zhang  et.  al  in  [42]  focused  on  creating  sequences  allowing  multiple  pairings  across 
the  spectrum  to  occur  every  time  slot.  In  other  words,  node  pairs  rendezvous  on  many  of 
the  available  channels.  The  algorithm  proposed  requires  pre-knowledge  of  the  number  of 
nodes  in  the  network  and  a  homogeneous  system  view.  This  method  also  utilized  by  Xin 
et.  al  in  creating  the  Rendezvous  with  near-Optimal  Performance  (ROP)  algorithm  was 
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designed  to  distribute  the  rendezvous  load  over  all  available  channels  [41].  The  benefit  of 
this  multiple  pairing  method  lays  in  the  number  of  simultaneous  connections  which  cause 
the  network  throughput  to  greatly  increase. 

Wu  &  Wu  found  little  attention  had  been  shown  to  recognize  the  difficulties  of 
utilizing  radios  capable  of  measuring  different  spectrum  spans  [39].  As  such,  the  last 
significant  scenario  covers  a  specific  situation  using  heterogeneous  systems.  A 
heterogeneous  system  refers  to  radios  in  the  system  using  different  operating  ranges,  and 
attempts  to  communicate.  For  instance,  if  radio  A  operates  on  frequencies  1-2  GHz  and 
needs  to  communicate  with  radio  B,  which  operates  at  1.5  -  2.5  GHz,  then  radio  A  and  B 
overlap  operational  frequencies  in  the  1.5-2  GHz  range.  This  overlap  allows  rendezvous 
to  occur.  In  2012,  research  papers  began  to  focus  on  this  new  consideration  for 
rendezvous.  Wu  &  Wu  addressed  this  by  presenting  the  interlocking  channel  hopping 
(ICH)  algorithm  which  utilizes  the  intersection  of  two  frequency  spans. 

2.2.2  Limitations  in  rendezvous. 

Most  of  the  scenarios  above  allow  communication  to  occur  for  only  a  fraction  of  the 
operating  time.  Pre-determined  frequency  sequences  for  rendezvous  do  not  allow  for 
constant  communication.  With  the  exception  of  the  organized  hop  method,  multiple  radios 
do  not  maintain  an  established  connection  for  more  than  one  time  slot. 

Furthermore,  the  researched  algorithms  described  above  presented  common 
assumptions  by  the  authors.  Most  algorithms  defined  a  rendezvous  as  successful  when 
“two  nodes  access  a  channel  during  a  certain  period  of  time  which  is  long  enough  to 
establish  a  reliable  link.”[33].  [2],  [4],  [5],  [35],  and  [39]  expressed  this  in  alternate 
wording.  This  imposed  the  restriction  of  operating  only  within  FPSFH. 

As  a  focus  point,  this  research  investigates  rendezvous  for  FHSS  systems  which  may 
operate  at  frequency  rates  defined  by  SPSFH  and  FFH.  SPSFH  is  critical  for  the 
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application  of  military  radio  operation.  As  such,  this  effort  explores  a  robust  method  of 
rendezvous  capable  of  supporting  both  slow  and  fast  frequency  hopping. 

2.2.3  Sequence  Estimation  with  Gold’s  time  of  arrival  algorithm. 

Only  two  possibilities  exist  for  rendezvous  without  the  ability  to  establish  a  reliable 
communication  channel  on  a  single  frequency  hop  as  with  FPSFH.  Either  the  the  radio 
must  have  complete  foreknowledge  of  the  network’s  hopping  sequence,  or  it  must  have 
the  ability  to  identify  the  current  hopping  sequence  of  the  network.  The  first  case 
describes  traditional  radio  operation  using  the  COD  method.  For  the  latter  case,  Gold’s 
algorithm  provides  a  process  to  calculate  the  hopping  sequence  of  a  network  by 
monitoring  a  single  communication  channel. 

Dr.  Robert  Gold  created  the  algorithm  as  part  of  a  Small  Business  Innovative 
Research  contract  with  the  US  Air  Force  Sensors  Directorate,  Air  Force  Research  Labs, 
Wright-Patterson  AFB,  OH  [28]  [29].  Additionally,  Robert  Gold  Comm  Systems  Inc 
patented  the  algorithm  [13].  No  academic  publications  of  this  algorithm  are  known. 

Golds  algorithm  functions  by  estimating  the  state  of  a  Linear  Leedback  Shift 
Register  (LLSR)  based  Pseudo-Random  Number  Generator  (PRNG)  sequence.  LLSRs  are 
commonly  used  to  create  the  hop  sequences  of  FHSS  systems.  The  algorithm  is  designed 
to  measure  the  time  differences  between  arrivals  of  a  radio  system  transmission  on  a  single 
channel.  The  operation  of  the  algorithm  requires  specific  parameters  of  the  target  LFSR 
system  to  be  known.  The  parameters  include  the  hopping  rate  of  the  target  system,  the  bit 
length  of  the  LFSR,  and  which  LFSR  bits  are  used  as  feedback.  Requiring  knowledge  of 
the  parameters  limits  cross  design  development;  however,  current  radio  systems  that  use 
LFSR  based  PRNG  sequences  already  operate  with  similar  restrictions. 

By  monitoring  a  single  channel  for  the  arrival  times,  the  algorithm  calculates  the 
state  of  the  LFSR  bits  for  which  all  future  states  depend.  This  allows  the  algorithm  to 
serve  as  a  rendezvous  method  for  establishing  communications  with  an  existing  SPSFH  or 
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FFH  network.  A  full  packet  exchange  is  not  required  for  the  algorithm  to  function. 
Appendix  B  provides  a  full  description  and  example  of  Gold’s  algorithm  functionality. 

Due  to  the  applicability  of  Gold’s  algorithm  toward  current  military  radio  systems, 
this  research  establishes  the  algorithm  as  an  implementable  method  for  FHSS  rendezvous 
across  all  sub-categories.  Additionally,  the  development  of  an  FPGA  implementation  of 
Gold’s  algorithm  within  this  research  enables  system  hardware  requirements  to  be 
determined  as  well  as  support  the  creation  of  an  FHSS  DSA  radio  test  platform  for  use  by 
the  AFIT’s  Cognitive  Radio  Laboratory. 

2.3  Environment  Map  Exchange  Overhead 

For  a  DSA  enabled  radio  to  perform  as  part  of  a  network,  the  radios  must  coordinate 
a  common  picture  of  the  environment  in  which  they  operate.  The  concept  of  the  Radio 
Environment  Map  (REM)  was  introduced  to  coordinate  this  environmental  data. 
Originally,  an  integrated  database  consisting  of  layers  of  radio  environment  domains 
formed  the  REM  concept.  These  domains  included  geographical  features,  spectral 
regulations,  radio  location,  activities  of  the  radio,  user  policies,  and  past  experiences  [43]. 
Dedicated  network  sensors,  a  compilation  of  spectrum  authority  databases,  and  by  the  very 
radios  attempting  to  utilize  the  data  funnel  information  to  the  REM.  Figure  2.6  shows  a 
representation  of  data  fusion  to  create  a  REM  database.  A  separate  or  more  specific  REM 
can  exist  on  multiple  levels.  The  REM  concept  contains  a  vast  amount  of  information  to 
describe  the  environment;  therefore,  the  cognitive  radio  community  should  research  both 
the  methods  of  acquiring  information  for  the  REM  and  the  distribution  of  that  data. 

Determining  a  sensor’s  local  RF  environment  is  arguably  the  most  impacting  aspect 
of  developing  a  REM.  REM  creation  requires  transmission  detection  of  other  systems  in 
the  vicinity  of  operation.  Wellens  and  Mahonen  presented  an  array  of  both  practical  and 
theoretical  spectrum  sensing  methods  [37].  Additionally,  [36]  provided  a  comprehensive 
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Figure  2.6:  REM  as  an  integrated  database  [44] 


REM 


summary  of  current  methods  of  spectrum  sensing.  Shokri-Ghadikolaei  and  Fallahi  sought 
to  determine  an  optimal  sensing  sequence  to  produce  the  greatest  data  throughput  [34].  In 
coordination  with  the  sensing  methods,  the  number  of  sensors  control  the  accuracy  of 
representing  the  environment. 

Faint  et  al.  calculated  the  critical  number  of  nodes  are  needed  to  create  a  REM  that 
properly  represents  an  area.  The  value  depended  on  the  total  area  under  investigation  and 
the  locality  of  the  sensor  nodes  [9].  Similarly,  Hanif  et  al.  investigated  the  performance  of 
CR  networks  when  discrepancies  exist  between  the  REM  being  used  for  operation  and  the 
true  environment  [14]. 

After  local  REM  collection,  the  network  must  distribute  the  REM  to  the  other  nodes 
in  the  area  (decentralized  system),  or  to  a  master  node  or  database  (centralized  system). 
Routing  protocol  research  which  utilizes  REM  information  is  found  throughout  recent 
publications.  [8]  and  [19]  summarized  over  30  different  routing  protocols  showing  a  major 
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research  focus  on  the  routing  of  network  information  to  achieve  the  best  performance. 
However,  these  routing  protocols  assumed  that  the  neighboring  network  nodes  already 
share  REM  information.  Little  research  addresses  the  physical  dissemination  of  the  REM 
once  collected  by  the  sensor  systems.  Zhoa  et  al.  in  [44]  compares  REM  dissemination 
schemes  on  an  ad-hoc  network.  The  comparison  addressed  three  schemes:  a  network 
flooding  scheme,  an  optimized  link  state  routing  protocol  (OLSR)  scheme,  and  an 
application  specific  scheme.  The  study’s  focus  compared  the  average  number  of 
retransmission  of  REM  packets  (overhead)  transmitted  per  node  versus  number  of  nodes 
in  the  network.  Although  measuring  retransmission  provides  insight  into  extenuated 
overhead,  the  study  failed  to  address  the  effect  of  REM  exchange  to  the  average 
throughput  of  non-control  data  on  the  network  or  the  effects  to  system  packet  delay.  This 
research  document  intends  to  investigate  this  missing  information. 

2.4  Background  Summary 

This  chapter  presented  research  on  issues  inherent  in  cognitive  radio  development. 
Specifically,  it  addressed  the  current  state  of  rendezvous  algorithms  based  on  scenario 
applicability,  and  presented  known  research  in  evaluation  of  network  performance 
overhead  costs  caused  by  implementing  DSA.  This  study  of  previous  related  works 
revealed  an  oversight  in  research  for  methods  for  rendezvous  capable  of  operation  under 
both  SPSFH  and  FFH.  Additionally,  it  uncovered  a  lack  of  research  into  the  the  overhead 
requirements  involved  with  exchanging  REM  data  on  a  constant  contact  network. 
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III.  Methodology 


This  chapter  is  divided  into  two  experimental  sections  to  assist  in  organization 

and  presentation.  The  first  section  addresses  an  FPGA  implementation  of  Gold’s 
algorithm.  The  section  begins  by  summarizing  the  development  methods  and  initial 
testing  of  the  design.  It  then  presents  a  test  methodology  for  implementation  of  the 
hardware  design.  The  methodology  describes,  in  a  systematic  way,  the  process  of 
investigating  the  implementation’s  resource  requirements  and  timing  restrictions.  The 
second  section  of  the  chapter  presents  three  different  generalized  REM  exchange 
protocols  for  investigation,  and  the  proposed  experiment.  The  experiment  specifically 
examines  the  effects  of  the  REM  exchange  protocols  on  network  overhead  costs  in 
relation  to  network  scaling  and  performance. 

Through  the  above  development  of  a  hardware  system  and  the  experimentation,  this 
research  investigates  five  questions  about  FHSS  DSA  cognitive  radios: 

1 .  What  are  the  hardware  requirements  and  timing  restrictions  for  implementing 
Gold’s  algorithm  on  an  FPGA  based  testbed? 

2.  To  what  extent  does  coordination  of  radio  networks  through  hop  sequence 
estimation  allow  for  quicker  rendezvous  versus  current  method  of  key 
synchronization? 

3.  How  does  hop  sequence  estimation  perform  within  the  DSA  paradigm  regarding 
rendezvous  compared  to  current  methods? 

4.  How  do  different  REM  exchange  protocols  affect  the  network  overhead  costs  in 
relation  to  network  scaling  and  performance? 

5.  To  what  extent  does  network  size  limit  the  time  interval  between  REM  exchanges? 
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3.1  Hardware  Implementation  of  Gold’s  Algorithm 

3.1.1  System  Development. 

A  testbed  is  created  to  test  the  effectiveness  of  Gold’s  algorithm.  The  design  uses  the 
Xilinx  ML507  development  board,  which  does  not  have  the  ability  to  create  radio 
frequency  transmissions.  However,  it  does  possess  the  ability  to  record  and  play  audio.  As 
such,  the  audio  peripheral  is  used  instead  of  RF  as  an  analogous  medium  [40].  An  FPGA 
platform  is  chosen  for  implementation  for  two  reasons.  First,  FPGAs  offer  operation 
speeds  capable  of  supporting  the  computation  level  requirements  of  FHSS.  Secondly,  they 
offer  support  for  the  rapid  prototype  development  required  by  research.  Note  that  all 
current  AFIT  research  efforts  on  CR  are  directed  toward  Rice  University’s  Wireless  Open 
Access  Research  Platform  (WARP)  which  is  an  FPGA-based  system  [1]. 


Figure  3.1:  Top-level  system  architecture 


The  testbed  design  consists  of  both  a  transmitter  and  a  receiver.  Figure  3.1  presents 
the  top  level  architecture  of  the  system.  The  receiver  will  contain  the  implementation  of 
Gold’s  algorithm.  The  transmitter  design  uses  an  LFSR  with  variable  bit  length  to  create 
its  hopping  sequence.  The  bit  length,  L,  as  well  as  the  bits  selected  for  feedback  determine 
the  period  associated  with  the  hop  sequence.  The  capabilities  and  properties  of  LFSRs 
have  been  well  studied,  and  selection  of  feedback  bits  to  create  the  longest  period  is 
beyond  the  scope  of  this  paper;  however,  it  can  be  stated  that  the  longest  sequence  period 
possible  of  any  LFSR  is  equal  to  Lr  -  1  [27].  A  representation  of  an  LFSR  PRNG  is 
shown  in  Figure  3.2.  During  operation,  several  bits  within  the  LFSR  are  statically  selected 
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as  tap  bits.  The  maximum  number  of  operating  frequencies,  N,  of  the  system  determine 
the  number  of  tap  bits  needed  where  N  =  2#taps.  The  tap  bits  control  the  audio  frequency 
(equivalent  to  RF  channel)  used  for  transmission. 

The  receiver  serves  as  the  acquisition  device.  Functionally,  it  listens  for  the  audio 
tones  of  the  transmitter,  estimates  the  sequence  using  Gold’s  algorithm,  and  finally 
synchronizes  with  the  incoming  sequence.  To  perform  these  actions,  a  data  flow  occurs. 
First,  an  audio  microphone  collects  the  signals  produced  by  the  transmitter.  This  detected 
audio  passes  to  a  Fast  Fourier  Transform  (FFT)  core  that  translates  the  signal  into  the 
frequency  domain.  A  comparator  is  attached  to  the  output  of  the  FFT  core  to  detect  when 
a  single  selected  frequency  is  present.  The  presence  or  absence  of  the  frequency  detection 
signal  represents  the  communication  on  a  carrier  frequency  in  RF.  This  detection  signal 
serves  as  input  into  the  Gold’s  algorithm  IP  core.  The  IP  core  detects  the  time  of  arrival 
differences  for  the  frequency,  calculates  the  state  of  the  transmitter’s  LFSR,  and 
determines  the  appropriate  tap  bits  to  replicate  the  incoming  sequence.  Both  the  calculated 
LFSR  state  and  tap  bit  locations  pass  to  the  receiver’s  LFSR.  Upon  successful  estimation 
of  the  hop  sequence,  the  receiver  produces  verification  of  synchronization. 


3. 1.1.1  Gold’s  Algorithm  VHDL  Design. 

The  algorithm  IP  core  consists  of  seven  distinct  computation  processes,  or  blocks, 
and  a  top-level  wrapper  for  component  coordination  and  control.  Each  block  corresponds 
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with  a  phase  of  the  matrix  computations  implemented  within  Gold’s  algorithm. 

Appendix  B  provides  a  detailed  description  of  each  block’s  implementation  in  VHDL. 
Appendix  C  contains  the  VHDL  code  for  the  algorithm  core. 

3. 1.1.2  Initial  Design  Testing. 

Determining  hardware  requirements  and  timing  restrictions  first  requires  verification 
of  the  algorithm’s  functionality  when  implemented  in  the  design  described  above.  As 
such,  a  reasonable  initial  test  is  generated  to  determine  the  operation  of  Gold’s  algorithm. 
The  test  implements  a  radio  pair  capable  of  frequency  hopping  over  32  frequencies 
according  to  a  uniform  distribution.  This  test  therefore  utilizes  a  16-bit  length  LFSR  with 
five  feedback  taps  and  five  frequency  taps.  The  maximum  sequence  period  for  a  16-bit 
LFSR  is  65,535  cycles.  The  use  of  audio  tones  and  the  FFT  limit  the  frequency  hop  rate. 
For  demonstration  purposes,  the  hop  rate  is  set  to  6  Hz  or  six  frequencies  per  second.  A 
successful  demonstration  is  defined  as  proper  function  of  the  algorithm  to  synchronize  the 
receiver  to  the  transmitting  system.  For  system  testing,  it  is  assumed  that  no  interference 
tone  or  noise  generators  are  present. 

The  scenario  described  ensured  proper  operational  testing  of  the  testbed  design. 

Upon  implementation,  the  receiver  proved  the  proper  operation  of  Gold’s  algorithm  to 
synchronize  with  the  transmitting  audio  stream.  The  test  was  repeated  for  different 
transmitter  starting  states,  feedback  bits,  and  tap  bits  parameters.  This  initial  testing 
verified  that  the  algorithm  IP  core  functions  as  expected. 

3.1.2  Test  methodology  for  Experiment  1  -  Gold’s  algorithm. 

This  section  establishes  the  testing  methodology  for  determining  Gold’s  algorithm’s 
hardware  system  requirements  and  timing  limitations. 

3. 1.2.1  Parameters/Factors/Levels. 

Implementation  of  the  algorithm  depends  on  several  parameters  for  system  design. 
Some  parameters  significantly  affect  the  hardware  resources  required  for  implementation 
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as  well  as  the  maximum  clock  frequency  for  stable  operation.  These  significant  parameters 
define  the  design  factors,  and  are  varied  in  this  experimentation.  Understanding  the 
resource  requirements  enables  designers  to  properly  select  components  based  on  desired 
radio  capabilities  while  the  hardware  design’s  timing  limitations  restrict  the  operational 
speed  of  the  algorithm.  The  following  parameters  are  considered  in  this  experiment: 

1 .  Frequency  hop  rate  -  defined  as  the  speed  at  which  frequency  changes  occur, 
measured  in  hops  per  second.  The  maximum  value  for  this  parameter  is  limited  by 
the  maximum  operation  speed  of  the  algorithm  itself  when  implemented  in 
hardware;  however  using  modern  processors  the  reaching  this  rate  is  unlikely.  The 
frequency  hop  rate  is  determined  by  the  target  device  and  remains  constant.  The  rate 
does  not  directly  affect  the  required  hardware  resources  or  timing  constraints,  and 
therefore  is  not  to  be  considered  a  factor.  This  rate  must  be  known  for  Gold’s 
algorithm  to  function. 

2.  LFSR  bit  length  -  Bit  length  for  the  LFSR  are  selected  as  part  of  system  design 
requirements.  As  such,  the  length  significantly  affects  the  resource  requirement 
needed  for  implementation.  The  LFSR  bit  length  is  derived  from  the  desired 
sequence  interval  of  the  radio  system  where, 

.  ,  Sequence  period 

Sequence  interval  = - - - 

Frequency  hop  rate 

Proper  selection  of  the  feedback  bits  can  produce  a  maximum  sequence  period  of 
Lr  -  1.  For  military  applications,  it  is  common  to  have  the  requirement  that  the 
sequence  interval  be  greater  than  24  hours  so  that  the  hop  sequence  does  not  repeat 
over  within  one  day.  Eight  levels  of  bit  length  variation  are  examined:  8,  12,  16,  20, 
23,  28,  32,  36.  These  levels  allow  sequence  periods  of  255  to  68.719  million  cycles. 
Using  a  sequence  interval  requirement  of  24  hours,  these  levels  correspond  to  a  hop 
rate  range  of  one  hop  every  338  seconds  to  795,364  hops  per  second.  This  wide 
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range  covers  known  operational  hop  rates  of  modern  systems.  Four  bit  spacing 
between  levels  is  chosen  to  explore  FPGA  operations  that  allocate  partial  resources 
such  as  using  only  4-bits  of  an  8-bit  register. 

3.  Feedback  bits  -  Although  feedback  bits  determine  the  period  of  the  sequence,  the 
implementation  design  presented  allows  any  combination  of  feedback  bits  to  be 
selected  from  the  LFSR  at  system  startup  in  software.  As  such,  any  change  in  the 
selection  of  feedback  bits  does  not  affect  the  hardware  resources  or  timing 
constraints.  This  parameter  is  not  considered  a  factor  for  this  experiment. 

4.  Operational  frequency  range  (Tap  bits)  -  the  maximum  number  of  frequency 
channels  of  the  system  determines  the  number  of  possible  tap  bits,  N  =  2#taps.  For 
proper  operation,  the  receiver  must  have  foreknowledge  of  the  number  of  taps  bits 
used  by  the  transmitter.  The  variation  in  taps  significantly  changes  the  logic 
requirements  of  the  system.  Therefore,  the  number  of  tap  bits  affects  the  resource 
requirements  and  timing  limitations,  and  is  considered  a  factor  for  this  experiment. 
Seven  levels  for  the  number  of  tap  bits  are  examined:  4,  5,  6,  7,  8,  9,  and  10.  This 
selection  allows  for  systems  utilizing  from  16  to  1024  distinct  frequency  channels. 


Table  3.1:  Summary  of  Parameters/Factors  for  Gold’s  algorithm  experiment 


Factor 

Levels 

Frequency  hop  rate 

6  Hz 

LFSR  bit  length 

8,  12,  16,  20,  24,  28,  32,  36 

Feedback  bits 

Constant  in  hardware  (set  in  software) 

Tap  bits 

4,  5,  6,  7,  8,9,  10 
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3. 1.2.2  System  Metrics. 

System  metrics  for  this  experiment  focus  on  the  resource  requirements  to  implement 
the  Gold’s  algorithm  IP  core,  and  timing  limitations  imposed  by  the  implementation. 

Implementation  of  a  design  to  a  FPGAs  is  both  software  and  device  specific.  For  this 
experiment,  Xilinx  ISE  vl3.2,  application  0.61xd,  synthesizes  a  netlist  to  target  the  Xilinx 
ML-507  development  board,  revision  A,  which  utilizes  a  Virtex-5,  version  xc5vfx7dt, 
FPGA.  Xilinx  ISE  vl3.2  uses  the  Xilinx  Synthesis  Technology  (XST)  process  by  default, 
but  is  capable  of  supporting  the  3rd  party  synthesis  tools  of  Precision  from  Mentor 
Graphics  Inc.  and  Synplify  from  Synplicity  Inc.  The  default  synthesis  tool  will  be  used. 

This  software  produces  a  detailed  report  as  part  of  the  synthesis  process  which 
include  a  listing  of  used  resources.  This  report  provides  resource  information  at  three 
stages  during  synthesis  as  well  as  a  final  device  utilization  summary.  The  first  stage’s 
report  covers  the  initial  Hardware  Description  Language  (HDL)  synthesis  before  any 
optimization  occur.  This  stage  is  not  useful  since  it  contains  many  unneeded  connections 
and  components.  The  second  stage  covers  the  advanced  HDL  synthesis.  This  stage’s 
report  presents  the  system  resources  needed  in  terms  of  macro  statistics  after  a  high  level 
optimization.  The  final  stage  covers  the  low-level  optimization,  and  the  report  addresses 
specific  cell  usage.  The  device  utilization  summary  provides  a  global  view  of  the  resources 
used  for  synthesis  in  terms  of  slice  registers  and  slice  Look-up  tables  (LUTs).  A  slice  is 
the  principle  programming  resource  unit  of  an  LPGA.  A  single  slice  consists  of  both 
LUTs  and  Llip-Llop/Latches.  The  number  of  each  on  a  single  size  varies  depending  on  the 
LPGA.  As  such,  this  utilization  summary  is  specific  to  the  Virtex-5 ’s  onboard  resources, 
and  cannot  be  applied  to  all  LPGAs;  however,  examination  of  utilization  will  show  general 
resource  trends.  Both  the  utilization  summary  and  the  advanced  HDL  synthesis  report  will 
be  examined  and  compared  in  this  experiment.  The  Xilinx  XST  synthesis  report  also 
addresses  timing.  The  report  provides  expected  timing  restrictions  of  the  VHDL  design 
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implemented.  Specifically,  it  establishes  the  minimum  clock  period,  maximum  clock 
frequency,  minimum  input  arrival  time  before  clock,  maximum  output  required  time  after 
clock,  and  maximum  combination  path  delay  for  an  implemented  system.  Of  these,  this 
experiment  collects  and  analyzes  the  maximum  clock  frequency.  This  value  represents  the 
highest  clock  frequency  the  algorithm  can  be  utilized  on  the  Virtex-5  to  ensure  stable 
operation.  Note  that  this  value  is  not  equivalent  to  the  maximum  frequency  hopping  rate. 

3. 1.2. 3  Expected  results. 

FPGA  implementations  for  designs  typically  require  set  resources  for  the  complexity 
of  a  system.  This  experiment  investigates  the  several  configurations  of  a  working  design. 
As  such,  the  hypothesis  of  this  experiment  is  that  the  resources  required  to  create  the 
working  implementation  of  Gold’s  algorithm  can  be  estimated  given  LFSR  bit  length  and 
the  number  of  tap  bit.  Additionally,  an  estimate  of  the  the  maximum  clock  speed  should 
be  calculable  using  the  same  parameters.  The  estimations  are  based  solely  on  using  the 
Xilinx  XST  synthesis  tool  and  the  Virtex-5  targeted  device.  Although  other  devices  may 
differ  in  results,  one  device  under  test  should  provide  insight  into  implementations  on 
other  devices. 

3.2  REM  Exchange  Overhead 

In  a  network  of  radios,  a  universal  view  of  the  environment  must  exist  for  radios  to 
coordinate  changes.  Different  from  the  multi-dimensional  REM  concept  presented  in 
Section  2.3,  this  experiment  for  simplicity  utilizes  a  simple  logic  vector.  This  logic  vector 
represents  each  communication  channel  as  available  or  unavailable  using  binary  l’s  or  0’s 
respectively.  Each  radio  must  coordinate  its  local  REM  with  every  other  radio  in  the 
network  to  ensure  only  common  available  channels  are  utilized.  Figure  3.3  shows  the 
coordination  of  multiple  nodes  to  create  a  shared  REM.  The  dark  sections  represent 
unavailable  channels,  and  light  sections  represent  available  channels.  The  resulting  vector 
from  coordinating  multiple  REMs  across  a  network  is  the  master  REM  or  network  REM. 
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Analyzing  the  methods  of  sensing  the  environment  to  create  a  node’s  REM  is  outside  the 
scope  of  this  research. 


REMl 


REM2 


REM3 


Merge(REMl,  REM2,  REM3) 


Valid  Common  REM 


Figure  3.3:  REM  Merger  [22] 


After  a  system  rendezvous  occurs,  the  system  must  coordinate  the  information 
required  to  maintain  a  stable  connection.  The  specifics  on  exchange  or  distribution  are 
rarely  described,  and  seem  to  be  not  well  researched.  As  such,  this  thesis  examines  several 
exchange  protocols  for  transferring  control  or  REM  data  among  radios  to  determine  the 
expected  overhead  costs  and  scalability  of  the  network.  This  thesis  identifies  and  tests 
three  possible  exchange  protocols  for  a  constant  contact  network. 

The  simulation  models  implemented  in  this  research  are  modifications  of  the  IEEE 
802.11b  Wireless  Local  Area  Network  (WLAN)  computer  communication  specification. 
WLAN,  being  one  of  the  most  widely  used  standards  in  the  world,  was  selected  as  the  best 
starting  point  due  to  the  readily  available  OPNET  simulation  wireless  node  models, 
source  code,  and  documentation.  As  background,  IEEE  802.11b  contains  two  primary 
MAC  coordination  functions.  Distributed  Coordination  Function  (DCF)  is  the  basis  of  the 
standard  CSMA/CA  access  scheme.  For  DCF,  a  transmitting  node  first  listens  to  the 
medium  to  determine  if  any  other  nodes  are  transmitting.  To  negotiate  for  the  medium 
with  other  nodes,  a  contention  window  is  created.  This  contention  window  represents  the 
time  in  which  the  medium  can  be  taken  control  of  by  a  single  node.  To  avoid  colliding 
during  transmissions,  each  node  selects  a  random  backoff  interval  within  the  contention 
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window  to  stall  before  attempting  a  transmission.  The  first  node  to  complete  its  backoff 
time  and  determine  that  no  other  node  is  transmitting  may  take  control  of  the  medium. 
DCF  is  considered  the  normal  operating  condition  for  WLAN  [12]. 

The  second  primary  function  is  the  Point  Coordination  Function  (PCF).  PCF 
provides  a  contention-free  service  to  exchange  information.  The  access  point  of  the 
network  in  IEEE  802.1  lb  initiates  the  PCF  period  by  using  a  broadcast  beacon.  Once 
initiated,  the  access  point  controls  the  wireless  medium.  It  then  requests  and  sends  data  as 
needed.  The  PCF  period  lasts  until  the  access  point  relinquishes  control,  or  a  time  limit  is 
reached.  DCF  operations  start  once  PCF  period  ends.  The  existing  implementation  of 
these  functions  in  the  OPNET  wireless  nodal  model  (802.1  lb)  are  leveraged  to  implement 
the  three  exchange  protocols  for  determining  the  impact  of  REM  exchange  overhead  on 
user,  non-control,  traffic. 

These  function  are  the  foundations  for  the  OPNET  simulations  models  used  in  this 
experiment.  All  network  activity  using  WLAN  is  performed  in-band  since  commercial 
devices  rarely  contain  more  than  one  transceiver. 

3.2.1  REM  exchange  methods  and  model  design. 

This  experiment  examines  the  affects  of  three  general  exchange  protocols  for 
transferring  REM  information  among  the  network. 

3.2.1. 1  Polling  Protocol. 

The  Polling  protocol  is  a  centralized  network  design  based  on  IEEE  802. lib’s  PCF. 
Polling  requires  a  single  radio  to  be  assigned  the  position  of  ‘controller’  or  ‘master’  for 
each  exchange.  Theoretically,  this  control  radio  is  determined  through  one  of  many 
methods  to  include  longest  living  member  of  the  network,  based  on  MAC  serial  number, 
or  even  the  most  powerful  radio  in  the  system.  For  this  research,  the  control  radio  is 
selected  prior  to  simulation.  In  this  protocol,  the  control  radio  coordinates  the  local  REM 
from  each  radio  in  the  network  by  leveraging  the  polling  functionality  of  the  PCF.  Upon 
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protocol  initiation  to  take  control  the  medium,  each  radio  in  the  network  is  ‘polled’  by  the 
controller  as  a  request  for  the  radio  to  send  its  local  REM.  All  radios  in  the  network  are 
polled  individually  during  this  modified  PCF  period.  The  control  radio  then  computes  the 
master  REM  for  all  other  radios.  After  computation,  the  control  radio  broadcasts  the 
master  REM  to  the  members  of  the  network.  Figure  3.4  graphically  depicts  the  operation 
of  this  method.  Once  all  nodes  receive  the  master  REM,  the  network  switches  back  to 
normal  operation  using  the  DCF. 


Polling  Protocol: 


PIFS  RIFS  SIFS  PIFS  SIFS  DIFS 


Figure  3.4:  Polling  Protocol  for  REM  Exchange 


3.2. 1.2  Time  Division  Protocol. 

The  Time  Division  protocol  focuses  on  a  distributed  network  design  where  each 
radio  must  communicate  with  all  other  radios  in  the  network.  Each  radio  collects  the  local 
REMs  of  each  neighboring  radio  and  calculates  the  master  REM  for  itself.  This  method 
assumes  that  1)  every  radio  is  within  range,  2)  every  radio  uses  the  same  master  REM 
algorithm,  3)  each  radio  interprets  the  usage  of  the  master  REM  the  same  way,  and  4)  a 
pre-coordinated  execution  time  exists  within  the  network.  Figure  3.5  graphically  depicts 
the  operation  of  this  protocol.  Time  division  is  a  common  method  of  coordinating  a 
communication  medium.  For  this  protocol  to  work  in  REM  exchange,  each  node  must 
know  its  precise  order  within  the  network  to  determine  when  to  transmit.  The  Time 
Division  protocol  also  utilizes  a  control  radio,  but  this  radio  only  initiates  the  exchange 
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period.  For  simulation  testing,  the  node  order  schedule  is  determined  by  their  node 
identification  number. 


Time-Division  Protocol: 


PIFS  DIFS 


No  Response, 
skip 


Figure  3.5:  Time  Division  Protocol  for  REM  Exchange 


3. 2. 1.3  Exponential  Backoff  with  Priority  Contention  Protocol. 

Exponential  Backoff  with  Priority  Contention  Protocol,  referred  to  as  simply  the 
Priority  protocol,  presents  a  reduced  communication  protocol  to  exchange  REM 
information  among  network  radios.  As  with  the  other  protocols,  a  control  radio  is  selected 
among  the  radios.  The  exchange  Priority  protocol  works  in  three  stages.  First,  the  control 
radio  will  distribute  a  Suggested  Master  REM  (SMREM).  The  SMREM  consists  of  the 
controller’s  local  REM  along  with  any  other  known  restrictions/predictions  to  the 
environment.  In  Stage  2  each  non-control  radio  compare  their  local  REM  to  the  SMREM. 
If  a  radio  wishes  to  further  limit  the  SMREM  (i.e.  a  suggested  open  channel  is  detected  as 
unavailable),  the  radio  updates  the  control  node  with  the  ‘dispute’  information.  This 
method  functions  similarly  to  DCF  operations  except  that  only  REM  information  is 
exchanged  and  a  priority  backoff  system  is  used  to  maximize  the  reporting  process.  The 
selection  of  which  radio  has  priority  to  respond  to  the  control  node  is  performed  by 
reducing  the  contention  window  of  each  node  as  a  percentage  of  disputes.  Each  node 
adapts  its  contention  window  using  the  following  equation. 

disputes 

New  Window  =  Old  Window  x  (1 - : - ; — - — ) 

Size  of  REM 
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The  control  radio  incorporates  all  received  disputes  transmitted  from  network  radios. 
The  control  radio  waits  for  maximum  elapse  time  to  occur  after  a  dispute  to  indicate  all 
disputes  were  reported.  After  the  elapsed  time,  the  control  radio  performs  stage  3  which 
posts  a  final  master  REM  to  be  utilized  by  the  network.  Figure  3.6  graphically  depicts  the 
operation  of  this  method.  A  key  attribute  of  this  protocol  is  a  non-control  radio’s  ability  to 
listen  to  the  medium  during  this  exchange  period.  This  allows  a  radio  to  detect  if  another 
radio  reports  a  dispute  which  covers  the  listener’s  disputes.  If  this  occurs,  the  radio  no 
longer  needs  to  report  the  dispute.  In  this  protocol,  it  is  possible  that  two  nodes  select  the 
same  backoff  period,  and  attempt  to  transmit  at  the  same  time.  If  this  occurs,  the 
transmitting  have  no  immediate  indication  that  a  problem  occurred  while  all  other  nodes 
will  have  detected  the  collision.  These  transmission  error  nodes  will  discover  the  problem 
only  if  another  node  posts  an  dispute  after  the  collision  occurs  upon  which  they  will  queue 
another  dispute  response. 


Priority  Protocol: 


Control 

Radio 


PIFS  SIFS 

k-  ->i  k- 


Detect  no  use 


DIFS 

-H  k-_ 


->  TIME 


Other 

Radios 


<7777 


New  contention  time 


Figure  3.6:  Exponential  Backoff  with  Priority  Contention  Protocol  for  REM  Exchange 


3.2.2  Test  methodology  for  Experiment  2  -  Network  overhead. 

3.2.2. 1  Experimental  goal  of  simulation. 

This  simulation  generates  data  used  to  evaluate  the  three  methods  of  REM  exchange 
protocols  explained  above.  In  particular,  the  data  is  used  to  determine  how  the  different 
REM  exchange  protocols  affect  the  overhead  cost  in  relation  to  network  scaling  and 
performance.  Overhead  data  is  the  necessary  exchange  of  environment  data  (REM  data) 
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distributed  between  a  group  of  nodes  to  facilitate  future  communication.  This  experiment 
utilizes  a  simulated  wireless  network  for  evaluation  of  overhead  data  over  many  network 
configurations.  For  these  experiments,  a  network  is  considered  ‘degraded’  when 
throughput  of  normal  data  traffic  (non-REM  data)  is  reduced  by  a  threshold  of  10%.  This 
level  is  chosen  due  to  the  level  of  data  loss  acceptable  for  Voice  over  IP  operations. 

3.2.2.2  System  Under  Test. 

The  system  under  test  consists  a  virtual  network  created  using  the  Riverbed  OPNET 
modeler  suite,  version  15. 0. A. PL  1  (build  8165).  The  network  comprises  of  a  number  of 
wireless  nodal  models  designed  to  emulate  the  behavior  of  a  DSA  radio.  A  complete 
nodal  model  contains  the  entire  seven  layers  of  the  Open  Systems  Interconnection  (OSI) 
framework  model  (ISO/IEC  7498-1);  however,  to  limit  the  external  influences  of  each 
layer,  only  the  Network,  Link,  and  Physical  layer  are  implemented  within  the  models  of 
this  experiment.  Each  node  transmits  and  receives  both  normal  network  traffic  and  REM 
overhead  data  traffic;  however  only  the  amount  of  normal  network  traffic  (non-control 
traffic)  is  evaluated  within  the  collected  metrics.  The  transmission  characteristics  of  each 
node  is  modeled  using  OPNET’s  IEEE  802.11  wireless  suite.  These  models  utilize  a  radio 
transceiver  pipeline  consisting  of  a  13  step  sequence  to  evaluate  transmission  delay, 
antenna  gains,  propagation  delay,  background  and  interference  noise,  error  detection  and 
correction,  and  signal-to-noise  ratio  requirements  for  transmissions  between  any  two 
nodes.  For  simplification  of  the  problem  space,  each  node  is  assumed  to  be  within 
transmission  range  of  all  other  nodes  within  the  network.  All  nodes  in  the  network  remain 
stationary,  and  are  located  within  a  100m  by  100m  grid.  This  research  excludes  any  node 
mobility  due  to  the  added  scenario  complexities  that  would  be  required.  The  grid  shape 
and  dimensions  were  initially  selected  as  a  continuation  of  past  research  to  create  an  RF 
environment  test  set.  Although  the  test  set  results  proved  not  applicable  for  this 
experiment,  the  layout  ensures  a  consistent  design  for  the  simulated  network. 
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The  REM  exchange  protocol  used  is  the  component  under  test.  For  every  simulation 
setup,  each  node  in  the  network  uses  the  same  nodal  model  with  the  only  distinction 
consisting  of  the  selection  of  a  master  or  control  node  among  the  nodes.  Table  3.2  presents 
the  common  critical  OPNET  attributes  shared  by  all  nodes.  The  transmission  start  time 
describes  when  each  node  will  begin  attempting  to  transmit  non-control  data  traffic.  This 
allows  for  spacing  in  the  beginning  of  the  simulations.  Packet  size  for  non-control  data  is 
one  parameter  that  directly  affects  the  workload  put  on  a  network.  This  attribute  is  set  so 
that  the  average  packet  size  is  a  fixed  value  among  the  network.  The  other  attributes  help 
define  characteristic  features  of  the  system  under  test.  All  the  values  presented  are 
common  throughout  all  simulations  in  this  study. 


Table  3.2:  Node  Attribute  Settings 


Attribute 

Value 

Transmission  Start  time  (sec) 

exponential  1) 

Packet  Size  (bytes) 

exponential  1 024) 

Data  Rate 

1  Mbps 

Transmit  Power 

0.1  W 

Retry  limit 

7 

Buffer  Size 

256000  bits 

Maximum  Transmission  Unit 

1500  bytes 

Destination  address 

Random 

3.2.2. 3  Parameters. 

The  term  parameter  refers  to  any  setting  or  environment  variable  that  affects  systems 
performance.  These  parameters  are  divided  into  those  specific  to  the  system  or  to  the 
workload.  System  parameters  change  between  different  simulations,  but  remain  constant 
within  a  single  simulation.  The  amount  of  user  specified  non-control  data  traffic  placed  on 
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a  system  defines  the  workload  parameters.  Workload  parameters  can  vary  during  a  single 
simulation  over  time,  and  vary  for  different  users.  The  following  list  defines  the  system 
and  workload  parameters  for  the  system  under  test. 

•  REM  Exchange  Protocol-  The  protocol  under  test  that  explains  how  the  exchange 
of  REM  information  is  executed  among  the  nodes  in  a  network. 

•  Network  size  -  the  network  size  describes  the  number  of  simulated  nodes  within  a 
simulation.  Since  each  node  is  capable  of  transmitting  data,  every  additional  node 
increases  the  overall  data  workload  as  well  as  the  amount  of  overhead  data  required 
for  a  network  to  coordinate  REMs. 

•  REM  ETpdate  Interval  -  The  time  interval  between  initialization  of  the  REM 
exchange  procedure.  This  interval  can  occur  at  a  set  interval,  or  vary  based  on  the 
performance  or  state  of  network  operation.  As  the  interval  decreases,  the  amount  of 
overhead  data  required  to  be  processed  by  the  network  increases. 

•  Node  Separation  -  the  distance  between  any  set  of  nodes.  This  experiment  limits  all 
nodes  within  a  100m  by  100m  grid.  The  nodes  are  placed  10  meters  apart  (vertically 
and  horizontally)  to  create  100  possible  locations  (10  by  10)  grid.  The  nodes  are 
placed  in  a  growing  square  pattern. 

•  System  Channels  -  A  DSA  radio  system  is  limited  by  the  spectrum  its  transceiver 
can  operate.  The  system  bandwidth  is  divided  into  operating  channels  according  to 
the  transmission  protocol  utilized.  For  instance,  a  home  network  router  operating 
according  to  IEEE  802.11  in  North  America  operates  in  the  2400-2483.5  MHz 
frequency  range.  This  bandwidth  is  divided  into  79  maximum  possible  transmission 
channels  for  the  standard.  DSA  coordination  among  radios  will  limit  which 
channels  are  considered  usable.  The  maximum  channel  number  dictates  the  length 
of  the  REM  required  to  represent  the  bandwidth.  The  simulations  within  this 
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experiment  utilize  a  constant  of  2048  possible  channels  to  cover  a  larger  range  of 
possible  channels.  This  constant  length  of  the  REM  creates  a  constant  packet  size 
for  control  traffic  used  in  the  REM  exchanges.  Evaluating  cross  channel  interference 
is  beyond  the  scope  of  this  research,  so  each  channel  is  assumed  to  be 
non-overlapping  and  non-interfering. 

•  System  Data  Rate  -  the  system  data  rate  is  the  maximum  rate  at  which  data  is 
transferred  within  the  system,  typically  measured  in  bits  per  second.  This  rate 
impacts  the  time  required  to  transmit  and  receive  data  transmissions  thereby 
affecting  the  system’s  performance.  As  shown  in  Table  3.2,  all  nodes  use  a  data  rate 
of  1  Mbps. 

•  Data  Workload  -  the  data  workload  is  a  measure  of  the  amount  of  normal 
(non-control)  data  traffic  on  the  network.  With  OPNET,  data  workload  is  attributed 
to  the  packet  size  and  interval  of  arrival  of  data  from  a  higher  OSI  layer  to  the  MAC 
layer.  Both  size  of  packets  and  the  interval  between  packets  can  be  modeled 
according  to  random  distributions  or  set  as  a  constant  value  within  OPNET.  These 
parameters  impact  the  amount  of  normal  traffic  traversing  the  network.  As  displayed 
in  Table  3.2,  all  nodes  are  modeled  using  a  data  generation  interarrival  time  with  an 
exponential  distribution  and  an  average  packet  size  of  1024  bytes.  The  interarrival 
rate  between  packets  is  considered  a  factor  in  this  experiment,  and  is  discussed  in 
the  next  section. 

•  REM  similarity  -  the  performance  of  an  adaptive  REM  exchanging  network  can 
vary  with  the  similarity  of  local  REMs  between  the  nodes.  This  similarity  between 
REMs  is  based  on  the  environment  detected  by  the  radios,  and  the  threshold  used  to 
determine  the  presence  or  absence  of  a  signal  on  any  channel.  Similarity  can  be 
attributed  to  locality  to  interference  sources  and  node  separation. 
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3. 2. 2. 4  Factors. 


Factors  are  a  subset  of  the  parameters  that  are  varied  in  the  experiment.  Any 
parameter  not  considered  a  factor  remains  a  constant  throughout  the  experiment.  The 
following  factors  varied  within  this  study. 

•  REM  Exchange  Methods  -  This  experiment  evaluates  three  REM  protocols: 
polling,  time  division,  and  exponential  backoff  with  priority  contention.  All  three 
are  tested  individually  for  a  performance  comparison. 

•  Network  size  -  the  network  size  will  be  varied  to  represent  a  network  size  of  4  to 
100  nodes.  As  this  number  range  creates  a  larger  number  of  trials,  the  following 
levels  are  chosen  for  this  study:  4,  9,  16,  36,  49,  64,  81,  and  100.  These  eight  levels 
allow  for  each  trial  to  progressively  grow  in  the  number  of  nodes  while  maintaining 
node  separation  intervals.  Each  network  size  forms  a  square  grid  resulting  the 
following  configurations:  2x2,  3x3,  4x4,  5x5,  6x6,  7x7,  8x8,  9x9,  and  10x10. 

•  REM  Update  Interval  -  The  intervals  selected  for  this  experiment  are  selected 
specific  to  each  network’s  size.  Four  or  five  test  intervals  were  selected  for  each 
network  size.  The  number  of  nodes  in  a  network  directly  affects  the  minimum 
interval  required  for  the  network  to  function.  The  minimal  interval  is  the  maximum 
time  required  to  execute  a  REM  exchange.  Any  interval  smaller  than  this  minimal 
value  produces  a  network  condition  where  no  non-control  data  would  be  transferred 
resulting  in  an  unusable  network.  A  pilot  study  was  performed  to  approximate  the 
needed  values.  The  pilot  study  is  further  discussed  in  Chapter  4.  Table  3.3  displays 
the  interval  values  used  in  the  experiment  based  on  network  size. 

•  Data  Workload  -  the  data  workload,  like  the  REM  update  interval,  is  different  for 
each  network  size.  The  values  selected  for  the  experiment  were  determined  from  the 
pilot  study  of  a  baseline  network  (a  network  operating  without  performing  a  REM 
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Table  3.3:  Test  Levels  for  REM  exchange  intervals 


Nodes 

REM  Update  Interval  (sec) 

4 

0.25,0.5,0.75,  1.0 

9 

0.25,0.5,0.75,  1.0 

16 

0.25,0.5,0.75,  1.0 

25 

0.25,0.5,0.75,  1.0 

36 

0.5,  1.0,  1.5,  2.0 

49 

0.5,  1.0,  1.5,  2.0 

64 

0.5,  1.0,  1.5,  2.0 

81 

0.5,  1.0,  2.0,  3.0 

100 

1.0,  2.0,  3.0,  4.0,  5.0 

exchange).  The  identification  of  the  peak  data  throughput  for  each  network  size  in 
the  pilot  study  allows  the  experiment  to  narrow  the  number  of  test  value.  The  values 
in  Table  3.4  represent  the  inter- arrival  rate  at  each  node  to  be  used  in  the  experiment. 
The  values  are  used  as  the  average  to  an  exponential  distribution  function. 

•  REM  similarity  -  No  viable  existing  data  was  found  during  review;  therefore, 
characterization  scenarios  were  investigated  based  on  different  levels  of  REM 
similarity.  Four  generic  situations  were  created  to  provide  bounding  of  the  problem. 

-  In  the  first  scenario,  referred  to  as  the  Unique  Scenario,  all  nodes  contain  at 
least  one  unique  channel  that  must  be  disputed  (upper  bound). 

-  In  the  second  scenario,  referred  to  as  the  Identical  Scenario,  all  nodes  contain 
the  exact  same  available  channels  (lower  bound). 

-  In  the  third  scenario,  referred  to  as  the  Random  Scenario,  every  channel  in  a 
local  REM  is  randomly  selected  as  available  or  not  available  with  a  50% 
probability. 
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Table  3.4:  Test  Levels  for  Nodal  Data  Workload 


Nodes 

Packet  Interarrival  Rate  (msec)  per  node 

4 

20  to  150  with  step  size  10 

9 

100  to  200  with  step  size  10 

16 

200  to  300  with  step  size  10 

25 

340  to  450  with  step  size  10 

36 

500  to  800  with  step  size  20 

49 

720  to  1100  with  step  size  20 

64 

900  to  1 800  with  step  size  50 

81 

1200  to  2300  with  step  size  50 

100 

1600  to  2100  with  step  size  50 

-  Lastly,  a  single  scenario,  referred  to  as  the  Real  World  Scenario,  is  constructed 
to  represent  conditions  found  in  the  real-world  operations.  A  simplified 
representation  of  this  scenario’s  setup  is  shown  in  Figure  3.7,  and  described 
below.  The  purpose  of  creating  such  a  scenario  is  to  establish  plausible 
situations  that  may  be  encountered  by  a  working  network. 

The  Real  World  Scenario  consists  of  an  array  of  interference  towers 
surrounding  the  network  under  test.  Each  of  the  40  transmitter  towers  in 
Figure  3.7  represent  a  cluster  of  ten  separate  interference  sources  at  the 
specified  location  for  a  total  400  transmitters.  Each  source  within  a  cluster  is 
characterized  by  an  activity  setting  parameter,  an  interference  range  parameter 
and  its  location  (the  location  of  the  cluster).  The  activity  setting  is  the 
probability  of  being  an  active  transmitter.  Specifically,  the  ten  sources  operate 
with  a  10%,  20%,  30%,  40%,  50%,  60%,  70%,  80%,  90%,  or  100%  channel 
occupancy  rate.  No  transmitters  in  the  same  location  use  the  same  probability 
(i.e.  each  uses  a  different  rate).  At  the  beginning  of  each  simulation,  each 
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transmitter  will  randomly  select  an  interference  range  with  a  value  from  0  to 
140.  This  distance  along  with  the  location  of  the  transmitter  determines  which 
radio  nodes  are  affected  by  each  transmitter.  The  colored  circles  in  Figure  3.7 
are  an  example  of  the  interference  range  of  three  sources. 

This  Real  World  Scenario  accounts  for  both  spectrum  variation  over  time, 
and  locality  to  interference  sources.  As  such,  it  provides  a  reasonable  set 
plausible  RF  environments  for  the  simulations.  It  is  possible  for  a  tower  to 
affect  all  nodes,  no  nodes  or  some  nodes.  As  an  added  complexity,  the  design 
pairs  sources  on  either  side  of  the  grid  to  share  frequencies  (eg.  a  tower  on  the 
north  end  uses  the  same  channels  as  on  on  the  south).  Each  source  is  assigned 
a  range  of  10  channels  to  cover  2000  frequencies  between  the  paired  towers. 
The  48  remaining  channels  represented  in  a  REM  are  considered  always 
available.  This  design  simulates  a  larger  region  where  the  outlying  radios  may 
have  different  interference  sources  that  operate  on  the  same  frequency  channel. 
At  the  start  of  each  execution  of  the  REM  exchange  protocol,  every  node  in  the 
network  builds  its  own  local  REM  based  on  the  condition  of  the  interference 
towers  and  its  proximity  to  those  sources  which  are  active.  If  the  node  falls 
within  the  interference  range  of  an  active  transmitter,  the  10  frequencies 
controlled  by  that  active  tower  will  become  unavailable. 
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Figure  3.7:  Real-World  Scenario 
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3. 2. 2. 5  Performance  Metrics. 

The  OPNET  simulations  report  five  network  performance  metrics  for  analysis.  Each 
metric  provides  insight  into  the  functionality  and  costs  associated  with  the  REM  exchange 
methods.  All  metrics  are  measurements  of  the  normal  data  (non-control)  traffic  moving 
through  the  network. 

Network  Throughput  -  For  this  experiment  network  throughput  is  defined  by  data 
generated,  transmitted,  and  successfully  received  by  the  intended  destination  over  time. 
This  metric  represents  only  normal  data  traffic,  and  does  not  include  the  overhead  of  data 
exchanged  for  the  REM.  For  each  simulation,  a  control  node  initiates  the  REM  exchange 
procedure.  Each  other  node  responds  according  to  the  protocol  designated  for  the 
simulation.  Any  packets  transmitted  for  the  purpose  of  coordinating  REM  data,  including 
the  process  initiation  packet,  will  be  considered  an  overhead  packet.  Network  throughput 
is  measured  in  bits  per  second. 

Data  dropped  due  to  buffer  overflow  -  Each  node  is  capable  of  queuing  data  before 
transmission.  Data  packets  arriving  to  the  MAC  layer  of  a  node  from  the  node’s  internal 
packet  source  must  enter  the  queue  before  transmission.  The  hardware  of  a  radio 
transceiver  limits  the  size  of  queue.  Overflow  occurs  when  the  queue  is  at  maximum 
capacity,  and  the  packet  generator  pushes  the  packet  to  the  MAC  layer.  In  such  a  case,  the 
new  data  packet  is  discarded  by  the  MAC  layer.  The  amount  of  data  dropped  due  to  buffer 
overflow  indicates  a  network’s  ability  to  transmit  the  packets  generated  by  each  node. 

Data  dropped  is  measured  in  bits  per  second. 

Data  dropped  due  to  exceeding  retry  limit  -  A  wireless  network  contains  the  risk  of 
more  than  one  node  attempting  to  transmit  data  at  a  single  time.  This  event  is  called  a 
transmission  collision.  If  this  occurs,  each  node  can  attempt  to  retransmit  the  packet  at  a 
delayed  time.  A  set  maximum  number  of  retries  may  be  attempted  before  the  data  packet 
is  discarded  by  the  MAC  layer.  The  average  amount  of  data  dropped  due  to  this  retry 
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threshold  is  examined  in  this  experiment  to  track  the  rate  of  successful  delivery  of  network 
traffic.  Data  dropped  is  measured  in  bits  per  second. 

Retry  attempts  -  in  addition  to  data  loss,  the  number  of  retransmission  attempts  to 
successfully  deliver  a  packet  indicates  the  performance  of  a  network.  An  increase  in 
retransmission  attempts  signifies  a  highly  congestive  network  and  can  lead  to 
unacceptable  performance. 

Packet  Delay  -  Measured  in  seconds,  delay  is  defined  as  the  time  from  packet 
creation  by  the  packet  generator  to  the  time  the  packet  is  successfully  received  at  its 
destination.  Significant  packet  delay  impacts  the  usability  of  a  network  for  time  dependent 
transmissions. 

3. 2. 2. 6  System  Workload. 

For  each  simulation,  a  traffic  load  of  normal  data  is  generated  for  the  network  to 
process.  This  workload  is  a  function  of  the  network  size  and  the  workload  generated  by 
each  node.  The  system  workload  holds  constant  for  each  simulation,  but  varies  among 
batches  of  simulations  to  characterize  a  networks  ability  to  handle  differing  traffic  loads. 
The  maximum  load  is  defined  as  the  rate  of  traffic  generation  that  produces  the  peak 
maintainable  throughput  rate  for  a  network  configuration.  From  the  pilot  study  presented 
in  Appendix  A,  the  throughput  rates  that  occur  at  the  maximum  load  points  are  negatively 
correlated  to  the  size  of  the  network. 

3.2.2. 7  Experimental  design. 

A  complete  factorial  design  is  used  for  this  experiment.  Each  combination  of 
method,  network  size,  traffic  loads,  REM  update  interval,  and  scenario  is  executed  as  a 
single  simulation.  Varying  the  traffic  load  creates  a  simulation  batch,  and  multiple  batches 
are  executed  for  each  required  scenario.  The  Polling  protocol  and  the  Time-Division 
protocol  each  require  only  a  single  scenario  for  characterization,  while  the  Priority 
protocol  requires  the  four  distinct  scenarios  presented  above.  Each  separate  simulation  is 
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to  be  repeated  15  times  utilizing  a  different  seed  value.  The  varying  the  seed  value  (values 
1  to  15)  changes  the  outcome  of  OPNET’s  internal  random  number  generators  used  for 
both  traffic  load  parameters  and  the  REM  creation  of  the  Random  Scenario.  These 
multiple  runs  allow  the  establish  a  95%  confidence  interval  for  analyzing  the  collected 
performance  metrics.  Table  3.5  displays  a  matrix  of  factor  levels  for  the  execution  of  a 
single  scenario.  The  testing  of  each  scenario  consists  of  8,385  simulations.  A  total  of 
50,310  simulations  are  performed  to  characterize  the  three  REM  exchange  protocols. 

Table  3.5:  Test  Matrix  of  simulation  runs 


Network  size 

Data  Workload 

REM  update 

intervals 

Seeds  values 

total  simulations 

4 

14 

4 

15 

840 

9 

11 

4 

15 

660 

16 

11 

4 

15 

660 

25 

12 

4 

15 

720 

36 

16 

4 

15 

960 

49 

20 

4 

15 

1200 

64 

19 

4 

15 

1140 

81 

23 

4 

15 

1380 

100 

11 

5 

15 

825 

Total 

- 

- 

- 

8385 

32.2.8  Expected  results. 

Considering  the  number  of  transmissions  required  by  each  node,  the  length  of  REM, 
and  system  workload,  it  is  reasonable  to  hypothesize  that  the  Priority  protocol  for  REM 
exchange  will  prove  to  have  the  highest  scalability  among  the  protocols  tested  determined 
by  a  10%  degradation  from  a  baseline  network  in  regards  to  network  throughput. 
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However,  the  Time-Division  protocol  is  expected  to  provide  the  best  performance  for  a 
small  network.  The  Polling  protocol  and  Time-Division  protocol  are  expected  to  scale 
poorly  for  two  reasons.  First,  the  amount  of  overhead  traffic  is  expected  to  increase 
linearly  as  the  network  size  grows.  Secondly,  the  pilot  study  demonstrated  that  network 
throughput  diminishes  as  network  size  grows  due  to  higher  probability  of  transmission 
collisions.  On  the  other  hand,  the  performance  of  the  Priority  protocol  is  expected  to 
easily  adapt  to  larger  networks  since  not  all  nodes  are  required  to  transmit  information 
during  each  REM  exchange.  This  hypothesis  is  formed  from  the  expectation  that  more 
nodes  in  a  network  does  not  increase  the  amount  of  REM  traffic  transmitted.  The  ability  to 
sense  another  node’s  disputes  to  the  suggested  REM  allows  this  assumption. 
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IV.  Results  and  Analysis 


This  chapter  presents  the  results  and  analysis  of  two  experiments.  Section  4.1  details 
the  results  and  analysis  of  implementing  Gold’s  algorithm  on  an  FPGA.  Section  4.2 
describes  the  results  and  analysis  for  the  REM  exchange  simulation  experiment. 

4.1  Gold’s  Algorithm 

An  hardware  implementation  of  Gold’s  algorithms  was  constructed  to  determine  the 
timing  constraints  and  resource  requirements  in  various  configurations.  The  experiment 
synthesized  53  configurations  of  Gold’s  algorithm  for  comparison.  These  configurations 
varied  in  LFSR  bit  length  and  the  number  of  tap  bits.  This  section  first  presents  the  timing 
constant  results  for  the  implementations,  and  then  discusses  the  resource  requirements. 
Lastly,  the  performance  of  Gold’s  algorithm  as  a  rendezvous  protocol  is  examined. 

4.1.1  Timing  Limitation. 

The  term  timing  limitations  describes  a  restrictions  caused  by  the  routing  and  timing 
of  logic  gates  within  an  FPGA  design.  As  any  signal  flows  through  logic  gates  and 
through  the  routing  between  the  gates,  timing  requirements  must  be  meet  to  ensure  proper 
signal  propagation.  During  analysis  of  the  different  possible  signal,  the  path  that  requires 
the  most  time  to  propagate  through  is  defined  as  the  critical  path.  This  critical  path  is  the 
limiting  factor  for  determining  the  maximum  clock  frequency  that  a  system  can  correctly 
operate.  If  the  maximum  clock  frequency  is  exceeded  during  operation,  the  device  may 
not  function  as  expected,  and  report  invalid  results.  The  maximum  clock  frequency 
determined  each  tested  configuration  is  displayed  in  Table  4.1.  These  timing  results  were 
an  output  of  Xilinx  ISE  vl3.2  using  the  XST  synthesis  process. 

The  fastest  maximum  clock  frequency  occurred  in  the  least  complex  configurations 
while  the  slowest  occurred  in  the  most  complex  designs.  Analysis  of  the  timing  data 
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Table  4.1:  FPGA  Maximum  Clock  Frequency  (MHz) 


Number  of  Tap  bits 

4 

5 

6 

7 

8 

9 

10 

LFSR  bit  length 

8 

218.866 

223.564 

218.150 

218.866 

X 

X 

X 

12 

194.590 

181.291 

173.974 

175.131 

174.978 

164.042 

136.799 

16 

153.445 

150.966 

148.170 

148.324 

149.880 

146.306 

136.388 

20 

149.566 

129.820 

136.631 

120.424 

123.747 

122.145 

114.613 

24 

149.388 

133.672 

127.714 

107.411 

97.286 

104.373 

101.968 

28 

137.696 

121.788 

105.274 

98.561 

94.357 

86.088 

85.874 

32 

129.182 

108.507 

86.633 

86.483 

87.047 

75.792 

75.672 

36 

126.556 

93.371 

81.907 

79.264 

79.220 

74.532 

71.628 

showed  no  linear  or  polynomial  relationships  between  the  two  variables  and  the  timing 
results.  A  generic  trend  showed  that  increasing  either  variable  caused  a  decrease  in 
maximum  operational  clock  frequency.  This  was  an  expected  trend  for  any  hardware 
system.  Upon  further  investigation  into  the  synthesis  output  files,  it  was  shown  that  the 
largest  cause  of  timing  is  not  the  hardware  elements  themselves,  but  the  routing  of  the 
intermediate  signals  between  logic  elements.  For  instance,  in  the  synthesis  of  the  36-bit 
LFSR  with  10  tap  bits  configuration,  the  timing  restriction  occurred  in  the  Frequency  Tap 
stage.  This  signal  delay  consisted  of  19.9%  logic  delay  and  80.1%  routing  delay. 
Therefore,  improving  the  routing  between  elements  of  logic  could  increase  the  design’s 
maximum  clock  frequency.  The  routing  of  the  implemented  design  was  determined  by  the 
Xilinx  ISE’s  Map,  Place  and  Route  functions.  These  functions  handle  designs  based  on 
either  timing-driven  constraints  or  cost-based  constraints.  The  above  results  were 
generated  based  on  using  timing-driven  constraints;  however,  since  no  initial  timing 
requirements  existed  during  development  of  the  design  no  specific  timing  restraints  were 
fed  to  Xilinx  to  meet. 
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The  timing  restrictions  collected  represent  the  results  produce  by  only  one  synthesis 
tool.  Other  synthesis  tools  may  produce  different  results  based  on  the  exact  placement  and 
routing  of  logic  gates  and  signals.  Future  work  should  consider  extenuding  this  study  to 
use  other  synthesis  tools  for  comparison. 

4.1.2  Resource  Requirements. 

The  Xilinx  vl3.2  using  the  XST  synthesis  tool  reports  utilization  data  for  the 
implementation  of  Gold’s  algorithm  on  the  Virtex-5,  version  xc5vfx7dt,  FPGA.  The 
reports  for  each  configuration  include  both  register  usage  and  LUT  usage.  A  separate 
analysis  is  performed  for  each  of  these  two  types  of  resources. 

4. 1.2.1  Register  Utilization. 

An  analysis  of  the  synthesis  reports  showed  the  number  of  used  registers  in  the 
design  as  a  function  of  both  the  LFSR  bit  length  and  the  number  to  tap  bits.  Figure  4. 1  and 
Figure  4.2  show  the  resulting  register  usage  by  varying  each  parameter  independently. 
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Figure  4.1:  Register  Usage  vs  LFSR  bit 
length 
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Figure  4.2:  Register  Usage  vs  Tap  bits 


The  consistent  shape  of  each  line  plot  as  a  function  of  a  single  variable  signified  that 
the  cross  interaction  between  the  variables  is  minimal.  This  is  verified  with  through  the 


use  of  MATLAB’s  curve  fitting  toolbox  (v3.2.1).  Independently  the  above  charts  were 
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approximated  by  the  following  two  equations: 


Registers  =  4  x  L2  +  11.4  x  L  +  Ci,  where  L  =  LFSR  bit  length 

Registers  =  9.3  x  T3  -  151  x  T2  +  835.5  xT  +  C2,  where  T  =  number  to  tap  bits 

The  values,  C 1  and  C2,  represent  the  true  interactions  between  the  two  variables.  For 
simplification,  any  variable  confounding  was  ignored  to  create  a  single  simple  equation  to 
approximate  register  usage. 

Registers  =  9.3  x  T3  -  151  x  T2  +  835.5  x  T  +  4  x  L2  +  11.4  x  L  +  C3 

The  value  of  C3  was  determined  to  be  -1371  to  produce  the  best  fitting  regression.  For 
any  regression,  goodness  of  fit  calculations  determine  the  accuracy  of  the  equation. 
MATLAB  reported  three  factors  in  judging  goodness  of  fit. 

MATLAB  reported  a  Standard  Square  of  Error  (SSE)  of  2.109e+04  which  is  a 
measure  of  unexplained  variation.  MATLAB  also  reported  R-squared  value  of  0.9999,  and 
a  Root  Mean  Square  of  Error  (RMSE)  value  of  20.14.  These  value  hold  higher 
significance  than  SSE.  R-squared,  the  coefficient  of  determination,  is  a  measurement  of 
goodness  ranging  from  0.0  to  1.0  where  1.0  is  a  great  fit  while  0.0  is  a  bad  fit.  This  meant 
the  approximation  equation  significantly  defined  the  data  points.  RMSE  corresponds  to  an 
unbiased  estimate  of  error’s  standard  deviation.  Among  the  data  points  created  by  the 
different  configurations,  the  equations  estimated  within  2%  of  the  true  value  for  all  all 
except  one  outlying  value. 

4.1.2.2  LUT  Utilization. 

Figure  4.3  and  Figure  4.4  represent  the  LUT  usage  of  implementing  Gold’s 
algorithm.  Although  graphically  similar  to  the  register  usage  figures,  the  calculated 
regression  equations  to  describe  LUT  usage  were  not  consistent  over  the  data.  As  such,  no 
single  form  equation  could  be  created  to  accurately  estimate  the  hardware  requirements  in 
terms  of  LUT  usage.  From  the  data  presented  in  the  Utilization  Summary,  it  was 


51 


determined  that  LFSR  bit  length  significantly  influences  the  number  of  LUTs  over  that  of 
the  number  of  tap  bits.  This  influence  is  graphically  shown  by  the  steep  exponential  trend 
displayed  in  Figure  4.3. 
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Figure  4.3:  LUT  Usage  vs  LFSR  bit  length 


Figure  4.4:  LUT  Usage  vs  Tap  bits 


4. 1.2.3  Other  report  results. 

Examination  of  the  Final  Report’s  cell  usage  provided  a  breakdown  of  Basic 


Elements  of  Logic  and  Flip  Flops/Latches  required  for  implementing  the  algorithm.  The 


Advanced  HDL  Synthesis  Report  displayed  consistent  resource  usage  across  the  different 


configurations.  Table  4.2  summarizes  the  results  of  the  Advanced  FIDL  Synthesis  Report 


in  terms  of  Macro  Statistics.  These  macro  statistic  values  do  not  differentiate  the  size  of 


each  component.  For  instance,  the  multiplexer  size  for  each  configuration  was  based  on 


the  LFSR  bit  length  utilized.  A  full  chart  with  results  from  each  synthesis  report  is 


included  in  Appendix  A. 


4.1.3  Rendezvous  Performance. 

The  use  of  Gold’s  algorithm  is  not  always  the  best  choice  when  selecting  a 
rendezvous  scheme  for  FHSS  networks.  A  comparison  was  performed  on  the  estimated 
time  to  rendezvous  for  both  COD  method  and  Gold’s  algorithm.  The  COD  method 
demonstrated  a  faster  synchronization  time  when  initiated  early  in  the  code  cycle,  and  also 
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Table  4.2:  Advanced  HDL  Synthesis  Report  Macro  Statistics 


Macro  Statistic 


Value  or  equation 


Finite  State  Machines  1 


RAMs 


1 


Adder/Sub  tractor  L+l  1  (minus  1  if  L  is  multiple  of  16) 


Counters 


5 


Latches 


L+l 


Comparators 

Multiplexers 


2 


16  when  T  <  6,  else  17 


XORs 


L2 +  2*  L+l 


when  the  system  utilized  a  slow  hopping  rate.  Figure  4.5  graphically  represents  a 
cognitive  decision  curve  for  selecting  between  the  two  schemes.  The  FPGA  configuration 
with  a  36-bit  LFSR  and  10  tap  bits  produced  the  slowest  operational  speed  as  shown  in 
Table  4. 1 .  The  figure  represents  such  a  system  when  utilizing  its  maximum  clock 
frequency  of  71.628  MHz.  To  determine  the  optimal  rendezvous  scheme,  a  user  or  logic 
program  must  determine  an  operational  hop  rate  and  the  time  of  day  in  which  rendezvous 
is  to  occur.  If  intersection  on  the  figure  falls  within  the  yellow  shaded  region,  it  is  better  to 
use  Gold’s  algorithm.  If  the  intersection  falls  within  the  green  shaded  region,  the 
traditional  COD  method  is  the  better  choice.  This  boundary  curve  incorporates  the 
average  time  of  acquiring  the  needed  samples  for  Gold’s  algorithm  to  function,  the  time 
needed  to  run  the  algorithm  to  determine  the  system  parameters,  and  the  time  required  to 
catch  up  to  the  sequence  of  the  transmitter. 

4.1.4  Effects  of  sequence  interpretation  for  Dynamic  Spectrum  Access. 

The  current  design  of  the  testbed  and  implementation  was  created  to  verify  the 
functionality  of  Gold’s  algorithm.  Gold’s  algorithm  was  not  designed  to  specifically 
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x  104  Comparison  of  E(TTR)  (Clock  Freq  =  7 1 .628  MHz) 
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Figure  4.5:  Decision  chart  for  COD  vs  Gold’s  algorithm 

function  in  a  DSA  environment.  The  application  of  DSA  to  FHSS  functionally  changes 
the  performance  and  applicability  of  rendezvous  algorithms.  As  such,  different  DSA 
incorporation  methods  are  analytically  examined  in  this  section  to  determine  their  effects. 

4. 1.4.1  Skipping  on  channel  unavailability. 

The  skip  method  describes  the  functional  action  taken  by  a  MAC  protocol  when  a 
frequency  change  is  required  and  the  next  frequency  is  unavailable  for  use.  For  instance, 
imagine  a  system  that  uses  an  8-bit  frequency  map.  This  system  is  capable  of  operating  on 
any  of  2 8  (256)  frequencies.  Let  C,  be  the  operating  channel  of  sequence  S  at  time  slot  i. 

If  currently  in  time  slot  i,  the  assigned  channel  for  Ci+ 1  could  be  any  channel.  If  the 
desired  channel  CM  is  not  available,  the  system  will  simply  move  to  the  next  frequency  in 
the  sequence,  i  +  2.  This  effectively  removes  channel  C,+i  from  S .  This  skip  method  has 
the  benefit  of  maintaining  both  a  constant  network  connection  and  its  data  rate.  This 
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method,  although  valid,  will  break  any  implementation  of  Gold’s  algorithm  since  it 
effectively  changes  the  time  of  arrivals  between  frequencies. 

4. 1.4.2  Hold  on  channel  unavailability. 

The  hold  method  describes  the  functional  action  of  not  transmitting  on  an  unavailable 
channel,  and  not  modifying  the  hopping  sequence.  In  other  words,  if  a  radio  hops  to  a 
channel  that  is  known  to  be  unavailable,  it  will  simply  not  transmit  during  the  time  slot. 
This  holding  of  transmission  will  continue  until  an  usable  channel  is  selected.  Gold’s 
algorithm  is  compatible  with  this  method.  The  time  of  arrival  calculations  are  not  affected 
by  a  failure  to  detect  a  signal  (false  negative),  or  absence  of  a  signal  (true  negative).  A 
network  utilizing  the  hold  method  may  experience  reduced  data  rates.  Note  that  if  using 
FFH,  a  majority  voting  scheme  can  eliminate  the  data  rate  drop  if  unavailable  channels  in 
the  sequence  do  not  occur  one  after  another. 

4. 1.4.3  Modulus  of  available  frequencies. 

The  modulus  method  describes  interpreting  the  hop  sequence  based  on  the  number  of 
known  available  channels.  For  example,  say  a  radio  determines  that  only  215  out  of  256 
operating  channels  are  available.  In  this  case,  a  frequency  mapper  re-interprets  the  next 
raw  frequency  value,  such  as  channel  222,  as  a  function  of  modulus  215.  This  produces 
222  mod  215  =  7.  Therefore,  the  system  would  hop  to  channel  7.  This  method  remaps 
all  possible  outcomes  of  the  a  PRNG  to  the  set  of  available  channels.  By  this  modulus 
operation,  channel  usage  does  not  remain  uniformly  distributed  over  the  available 
channels.  Specific  application  of  this  method  to  Gold’s  algorithm  requires  thought  into  the 
application  of  the  algorithm  when  no  rendezvous  is  achieved.  Using  the  modulus  method 
generates  the  case  where  multiple  PRNG  values  being  assigned  to  a  single  channel.  These 
creates  a  problem  with  the  time  of  arrival  calculations.  Upon  detecting  that  a  single 
channel  has  multiple  assignments,  a  protocol  would  be  required  to  dynamically  change  the 
listening  channel.  This  sets  a  requirement  that  A/2+1  channels  must  be  available. 
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However,  the  modulus  method  remains  a  valid  approach  with  this  type  of  additional 
protocol. 

4.2  Protocol  Simulation 

This  section  discusses  the  wireless  network  simulation  results  used  to  compare  three 
possible  REM  exchange  protocols.  A  total  of  50,310  simulations  were  performed  to 
characterize  the  three  protocols.  Each  simulation  requires  an  average  of  20  seconds  to 
execute  resulting  in  a  total  run  time  of  approximately  1 1.6  days.  In  this  section,  each 
protocol  is  compared  to  a  baseline  network’s  performance  where  the  level  of  performance 
is  evaluated  using  five  metrics:  network  throughput,  data  dropped  due  to  buffer  overflow, 
data  dropped  due  to  exceeding  retry  limit,  retry  attempts  and  packet  delay.  These  metrics 
were  taken  for  normal  (non-control)  data  traffic  transmitted  on  the  network.  The  section 
continues  by  presenting  a  series  of  representative  examples  in  an  attempt  to  condense  the 
volume  of  data.  Appendix  A  contains  the  full  set  of  collected  results. 

4.2.1  Baseline  Results. 

A  baseline  assessment  of  the  simulation  network’s  performance  was  conducted  for 
each  network  size  over  several  data  workloads.  The  baseline  metrics  were  extracted  from 
the  pilot  study  and  used  to  select  several  of  the  experiment  factors.  Figure  4.6  displays  the 
network  throughput  for  several  network  sizes  over  changing  data  workloads.  This  baseline 
throughput  result  is  consistent  with  an  exponential  decrease  in  the  peak  average 
throughput  as  a  function  of  increasing  network  size.  The  peak  throughput  achieved  while 
using  each  of  the  exchange  protocols  will  be  compared  to  this  decreasing  exponential 
trend. 

The  baseline  data  also  displayed  a  near  linear  relationship  between  the  network  size 
and  the  traffic  workload  required  to  achieved  the  peak  throughput.  Figure  4.7  graphically 
represents  this  interaction.  Using  MATLAB’s  curve  fitting  toolbox  v3.2.1,  the  data  in 
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Figure  4.7  produced  a  best  fit  curve  estimate  of 

f{x)  =  0.03254  *  x2  +  13.8  *  x  -  14.81 

A  goodness  of  fit  evaluation  of  this  fit  curve  produced  a  standard  error  of  10.31  and  an 
adjusted  R-square  value  of  0.9997  indicating  a  good  representative  fit.  These  consistent 
trends  over  changing  network  size  make  network  throughput  an  ideal  metric  for 
determining  the  effects  of  REM  exchange.  Therefore,  each  of  the  three  exchange 
protocols  were  compared  to  these  baseline  results  to  determine  the  overhead  costs  of 
distributing  REM  information. 
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4.2.2  Network  throughput. 

Network  throughput  is  a  measure  of  the  amount  of  data  that  can  be  transferred 
through  a  network.  Of  all  the  metrics  collected  as  part  of  this  experiment,  network 
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Beacon  Interval  every  one  second 


Figure  4.7:  Correlation  of  Network  Size  and  Interarrival  Rate  for  Peak  Throughput 


throughput  provided  the  most  stable  and  useful  properties  for  analysis.  This  section 
examines  the  throughput  achieved  by  each  protocol,  and  how  REM  exchanges  affect 
performance  compared  to  the  baseline  network. 

4. 2. 2.1  Polling  and  Time-Division  Protocols. 

Both  the  Polling  protocol  and  Time-Division  protocol  performed  similarly  in  the 
simulations.  The  two  protocols  required  each  node  in  the  network  to  broadcast  their  local 
REM  during  each  exchange.  The  Polling  protocol  also  included  the  need  for  a  request 
packet  (poll)  to  be  sent  to  each  node  causing  additional  overhead. 

In  examining  throughput,  the  overhead  costs  increased  as  the  beacon  interval  become 
more  frequent.  Figure  4.8  shows  the  throughput  changes  for  a  16  node  network  as  a  result 
of  varying  the  exchange  interval.  Other  network  sizes  displayed  similar  results  of 
decreased  throughput,  but  at  different  magnitudes  of  change.  This  behavior  is  to  be 
expected  since  the  more  exchanges  that  occurred  allowed  less  normal  traffic  data  to  be 
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transmitted.  As  a  bound,  consider  that  the  beacon  interval  must  be  greater  than  the  time 
required  for  an  exchange  to  occur.  For  the  simulations,  any  beacon  interval  more  frequent 
than  this  bound  caused  the  simulation  to  crash.  The  examination  of  the  16  node  network 
was  chosen  over  the  other  network  sizes  because  of  the  clear  separation  of  the  data  lines. 
Figure  4.8  as  a  representative  sampling  of  the  other  network  sizes  also  showed  a 
non-linear  relationship  to  the  overhead  costs  as  the  interval  changed.  A  linear  relationship 
would  display  a  constant  change  in  throughput  for  the  interval  rates  tested.  As  described 
in  Table  3.3,  the  simulation  of  each  network  size  used  a  unique  set  of  exchange  intervals 
for  testing.  Each  network  size  contained  a  beacon  interval  of  one  second  to  allow  a  direct 
comparison  of  the  REM  protocols. 
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Figure  4.8:  Polling  Protocol  -  Throughput  for  a  16  node  network 


Taking  the  peak  throughput  for  each  network  size  at  a  one  second  beacon  interval 
produced  Figure  4.9.  This  figure  displays  a  comparison  of  the  peak  throughput  for  the 
Polling  protocol  and  the  Time-Division  protocol  against  the  baseline.  As  shown  in  the 
figure,  the  use  of  the  Time-Division  protocol  produced  average  throughput  values  higher 
than  the  Polling  protocol.  The  addition  of  the  polling  packets  explains  the  difference  in  the 
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throughput  levels.  The  deviation  from  the  baseline  performance  increased  as  the  number 
of  nodes  in  the  network  increased.  Figure  4.10  shows  this  deviation  as  a  percentage  of  the 
baseline  throughput.  Note  that  both  protocols  function  worse  as  the  network  size  grew. 
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A  side-by-side  comparison  of  three  different  beacon  rates  reinforced  that  deviation 
from  the  baseline  is  minimized  as  the  REM  exchange  interval  increases.  Figure  4.1 1 
shows  the  deviations,  and  how  both  the  Polling  protocol  and  Time-Division  protocol 
performed  similarly  each  situation. 
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4.2.2.2  Priority  Protocol. 

The  simulations  testing  of  the  Priority  protocol  required  testing  four  scenarios.  The 
other  protocols  only  required  a  single  scenario  since  every  node  was  required  to  transmit 
its  individual  REM  during  each  exchange.  The  Priority  protocol,  however,  functions  based 
on  the  similarity  in  the  REMs  of  the  network  nodes.  The  four  scenarios  created  upper  and 
lower  boundaries  of  operation  as  well  as  provided  two  examples  of  possible  operational 
conditions.  The  Unique  scenario  was  the  lower  bound  scenario  which  represented  a 
situation  when  every  node  contained  at  least  one  unique  channel  restriction  resulting  the 
most  network  activity.  The  Identical  scenario  was  the  upper  bound  scenario  where  all 
nodes  contained  the  same  local  REM  requiring  only  minimal  network  activity.  Lastly,  the 
Random  and  Real  World  scenarios  represented  two  conditions  where  parts  of  the  RF 
environment  are  shared  among  nodes.  As  an  representative  example  of  the  data  collected 
in  simulation,  Figure  4.12  displays  the  network  throughput  results  for  each  scenario  on  a 
36  node  network.  These  graphics  are  presented  to  show  the  general  differences  produced 
by  the  scenarios.  Appendix  A  contains  complete  data  charts  for  each  network  size  tested. 
The  examination  of  the  36  node  network  was  chosen  over  the  other  network  sizes  because 
of  the  clear  separation  of  the  data  lines,  and  to  allow  a  direct  comparison  against  the  data 
presented  for  the  other  protocols. 

As  with  the  Polling  and  Time-Division  protocols,  results  for  the  Priority  protocol  in 
each  scenario  explored  the  effects  of  the  interval  between  beacons.  Comparing  the  peak 
average  throughput  of  each  scenario  allowed  for  the  expected  operational  range  to  be  seen. 
Figure  4.13  expresses  this  comparison  at  a  beacon  interval  of  one  second.  The  figure 
shows  that  the  Unique  scenario  (lower  bound)  diverged  from  the  baseline  as  the  size  of  the 
network  increased.  The  Identical  scenario  (upper  bound)  converged  to  the  baseline 
throughput  value  as  the  network  size  increased.  A  major  constraint  in  throughput  arose  as 
more  collisions  occurred.  For  larger  networks  within  the  simulation,  each  node’s  constant 
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Figure  4.12:  Priority  Protocol  -  Throughput  for  a  36  node  network 


and  equal  amount  of  traffic  drove  the  collision  rate.  The  amount  of  normal  data  traffic  that 
was  sent  during  the  REM  exchange  time  was  minimized  due  to  the  collisions,  and  this 
explains  the  convergence  of  the  the  baseline  and  Unique  scenario  values.  All  simulations 
in  these  experiments  required  each  node  in  the  network  to  share  an  equal  traffic  load.  The 
Random  and  Real  World  scenarios  performed  as  expected.  Each  produced  statistically 
similar  values  for  networks  of  small  size,  and  tracked  closer  to  the  upper  bound  than  the 
lower  bound.  To  better  understand  the  amount  of  nodal  interaction  occurring  within  the 
scenarios,  the  simulation  collected  additional  information  100  node  network  size 
simulations  to  determine  the  average  number  of  packets  (overhead)  successfully 
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transmitted  during  a  REM  exchange.  This  value  provided  awareness  of  the  REM 
similarity  that  each  scenario  produced.  The  simulations  for  the  Random  scenario  required 
an  average  of  6.9  packets  with  a  standard  deviation  of  0.34  packets.  The  simulations  for 
the  Real  World  scenario  required  an  average  of  12.05  packets  with  a  standard  deviation  of 
2.24  packets.  If  collected,  the  Unique  scenario  would  have  produced  a  value  of  100 
packets,  and  the  Identical  scenario  would  have  produced  a  value  of  zero  packets.  Together 
these  values  show  strong  correlations  to  the  loss  in  average  throughput  from  the  baseline. 

Viewed  as  percentage  of  the  baseline,  shown  in  Figure  4.14,  its  clear  that  the  Random 
and  Real  World  scenarios  display  a  convergence  to  the  baseline  as  the  network  size 
increased.  At  a  network  size  of  100  nodes,  the  peak  average  throughput  of  both  scenarios 
approach  or  exceed  the  90%  functionality  threshold.  The  assumption  that  every  node  was 
within  communication  range  during  simulation  limited  the  number  of  packets  required  in 
each  REM  exchange.  However,  since  the  design  of  the  Real  World  scenario  intended  to 
cover  many  of  the  possible  RF  environments,  this  gives  confidence  that  the  number  of 
exchanges  in  other  real-world  scenarios  would  also  function  with  a  limited  number  of 
exchanges  being  required. 
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4.2.3  Data  dropped  due  to  buffer  overflow. 

In  the  OPNET  model,  each  node  generated  normal  data  traffic  for  the  network  to 
process.  The  amount  of  data  created  by  each  node  was  defined  by  the  size  of  each  packet 
and  the  interarrival  rate  of  the  node’s  packet  generator.  As  shown  in  Table  3.2,  each  node 
consisted  of  a  transmission  buffer  capable  of  holding  256 K  bits  of  normal  (non-control) 
data.  The  buffer  fills  as  packet  generation  exceeds  a  nodes  ability  to  transmit  the  data.  If  a 
the  data  buffer  is  at  max  capacity,  and  if  a  new  data  packet  arrives  for  the  node,  that  new 
packet  is  discarded.  The  amount  of  data  discarded  was  tracked  by  the  data  dropped  due  to 
buffer  overflow  metric. 

For  any  REM  exchange  interval,  the  buffer  drop  rate  maintained  near  zero  packet  loss 
until  the  critical  packet  generation  rate  was  reached.  This  critical  point  indicated  that 
maximum  supported  workload  that  the  network  could  successfully  process  without  loss 
occurring.  Additionally,  examining  this  point  of  first  overflow  revealed  a  correlation  in  the 
data  workload  to  the  occurrence  of  the  peak  throughput. 

Figure  4.15  and  Figure  4.16  display  an  example  of  this  correlation.  These  figures 
show  an  81  node  network  operating  with  the  Time-Division  protocol.  The  figures, 
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showing  four  different  beacon  intervals  and  the  baseline,  demonstrate  that  the  occurrence 
of  peak  throughput  and  first  buffer  overflow  correspond  to  the  same  network  workload. 
This  correlation  is  found  through  the  simulation  results  regardless  of  network  size  or 
protocol.  When  more  traffic  is  generated  than  the  buffer  can  hold,  the  result  is  for  the  node 
always  to  have  data  available  for  transmission. 
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4.2.4  Data  dropped  due  to  exceeding  the  retry  limit. 

The  data  dropped  due  to  the  retry  limit  metric  produced  inadequate  results  for  a 
comparison  analysis.  For  most  simulations,  the  metric  reported  values  of  zero. 
Investigation  into  the  model’s  code  showed  a  possible  reason  for  these  results.  In  the 
program  code  of  the  model,  a  normal  data  packet  queued  for  re-transmission  was  dropped 
if  interrupted  by  a  REM  exchange.  No  metric  monitored  this  dropped  packet,  and  it  was 
lost  in  the  system.  The  program  assumed  that  the  packet  was  properly  handled  resulting  in 
a  reset  of  the  retry  counter.  A  relatively  short  REM  exchange  interval  therefore  restricted  a 
packet  from  reaching  the  maximum  retry  limit.  Only  packets  reaching  the  limit  were 
counted  as  part  of  the  metric.  This  problem  is  in  the  implementation  of  the  model  and 
does  not  reflect  the  performance  of  the  protocols.  However,  this  zero  value  problem 
eliminates  the  dropped  data  due  to  exceeding  the  retry  limit  metric,  and  is  omitted  from 
further  analysis  of  the  results. 

4.2.5  Retry  attempts. 

Attempting  to  track  total  retry  attempts  as  a  metric  also  proved  problematic  due  to 
the  model  code  issue.  For  the  retry  attempts  metric,  the  Polling  and  Time-Division 
protocol  displayed  the  most  consistent  results.  Figure  4.17  illustrates  the  results  of  this 
metric  for  the  81  node  network  simulation  using  the  Time-Division  protocol.  This  figure 
verifies  two  expected  characteristics  for  retry  attempts.  First,  the  maximum  average  retry 
attempts  should  be  similar  among  REM  update  intervals  with  the  maximum  value  as  a 
function  of  network  size.  Second,  as  the  exchange  interval  decreases,  the  workload 
required  to  reach  the  maximum  average  attempts  should  also  decrease.  Unlike  the  Polling 
and  Time-Division  protocol  simulations,  the  Priority  protocol  produced  results  that  were 
inconsistent  with  the  expectations  of  a  network’s  performance  in  terms  of  delay.  Only  a 
small  amount  of  retry  attempts  were  recorded  when  utilizing  the  Priority  protocol.  This 
was  most  likely  due  to  the  same  model  code  as  described  above.  Due  to  the  inconsistency 
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in  the  reporting  of  the  metric  among  protocols,  the  retry  attempt  metric  was  not 
investigated  further  in  this  analysis. 


Time  Division  Average  Retry  Attempts,  8 1  Nodes 


1°000  1200  1400  1600  1800  2000  2200  2400 


N=8 1  ,beac=none 

N=81,beac=0.5 

N=81,beac=l 

N=81,beac=2 

N=81,beac=3 


Interarrival  Rate  (msec) 

Figure  4.17:  Average  Retry  Attempts,  Time-Division  Protocol,  81  nodes 


4.2.6  Packet  delay. 

The  delay  metric  collected  the  average  amount  of  time  to  deliver  a  successful  packet; 
however,  it  did  not  track  the  number  of  packets  that  were  successfully  delivered.  The  REM 
exchange  interval  and  the  protocol  itself  limit  the  total  amount  of  traffic  to  successfully  be 
delivered  as  seen  by  the  network  throughput  results.  If  the  system  successfully  transmitted 
only  a  single  packet,  then  that  one  packet’s  delay  would  be  used  in  defining  the  metric 
value.  Even  with  this  limitation  in  data  collection,  a  useful  insight  can  be  gained. 

Figure  4.18  corresponds  the  same  81  node  network  described  in  the  Section  4.2.3.  This 
figure  displays  the  alarming  amount  of  delay  that  occurs  in  high  workload  network 
conditions.  The  delay  quickly  exceeds  any  acceptable  level  of  delay  at  the  same  workload 
conditions  that  the  buffer  began  to  overflow.  The  coarseness  of  available  data  points  do  not 
allow  for  analysis  of  the  max  delay  before  the  precise  workload  that  causes  the  delay  to 
rise;  however,  results  before  this  critical  workload  seem  to  be  similar  to  the  results  of  the 
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baseline  network.  As  such,  the  performance  of  the  network  is  driven  by  the  beacon 
interval,  and  the  amount  of  time  needed  to  perform  a  REM  exchange. 

The  Polling  and  Time-Division  protocols  displayed  similar  similar  delay  growth  for 
all  network  sizes.  However,  the  Polling  protocol  required  less  of  a  workload  to  begin 
increases  in  delay.  The  collection  of  the  packet  delay  metric  for  the  Priority  protocol 
resulted  in  inconclusive  data  which  cannot  be  compared  to  the  other  protocols. 
Specifically,  the  results  suggested  that  almost  no  delay  was  recorded  among  packets  which 
indicates  a  problem  in  the  collection  methods.  Packet  delay  may  be  a  limiting  performance 
issue  when  Quality-of-Service  is  required  for  network  operation,  but  the  results  of  this 
research  do  not  provide  the  resolution  needed  to  analyze  such  performance  requirements. 
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Figure  4.18:  Average  Retry  Attempts,  Time-Division  Protocol,  81  nodes 


4.2. 7  Further  Testing. 

As  stated  above,  several  of  the  metrics  could  not  be  analyzed  due  to  an  error  in 
packet  handling  within  the  program  code  of  the  model.  This  code  error  was  identified  and 
corrected.  Data  was  then  collected  on  this  corrected  model  using  the  same  methodology 
as  described  in  Section  3.2.  The  analysis  of  this  data  proved  to  be  statistically  inconclusive 
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due  to  the  large  variations  of  the  confidence  intervals.  An  example  of  variations  in  the 
results  are  shown  in  Figure  4.19.  The  figure  displays  the  peak  throughput  for  the  Priority 
protocol  under  each  of  the  four  scenarios.  As  shown,  the  confidence  intervals  constructed 
using  15  iterations  of  each  simulation  setup  provides  no  statistical  differences  for 
conclusions  to  be  drawn.  To  properly  analyze  this  updated  model  additional  iterations  are 
required  to  reduce  the  95%  confidence  intervals;  however,  due  to  time  limitations  these 
iterations  will  not  performed  as  part  of  this  research  effort,  but  should  be  considered  in  any 
future  work. 

xlO5  Peak  Throughput  at  Beacon  every  1  second 


Baseline 

Priority  -  Unique  Scenario 
Priority  -  Identical  Scenario 
Priority  -  Random  Scenario 
Priority  -  Real  World  Scenario 

°0  20  40  60  80  100  120 

Network  Size 

Figure  4.19:  Peak  Throughput  for  Priority  protocol  (updated  results) 
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V.  Conclusions 


This  chapter  summarizes  the  goals  and  conclusions  of  this  research.  Section  5.1 
presents  the  goals  and  results  of  the  studies.  Section  5.2  outlines  the  significance  of  this 
research.  Lastly,  Section  5.3  provides  suggestions  for  future  research  into  cognitive  radio. 

5.1  Research  Goals  Acheived 

The  first  goal  of  this  research  was  to  demonstrate  that  Gold’s  algorithm  allows  for 
successful  rendezvous  on  an  FHSS  radio  network  without  dwell  time  or  common  control 
channel  requirements.  Development  and  demonstration  of  the  FPGA  based  algorithm,  as 
described  in  Section  4.1,  showed  successful  rendezvous  with  Gold’s  Algorithm.  The 
design  proved  that  detection  of  a  signal  on  a  communication  channel,  regardless  of  dwell 
time  or  specific  channel,  allows  for  rendezvous  to  occur.  The  system  also  includes 
limitations  in  terms  of  operational  applicability.  The  algorithm  itself  cannot  handle  false 
positives  within  signal  detection.  A  false  positive  requires  the  algorithm  to  reset  since  a 
solution  will  not  be  found.  This  results  in  a  possible  jamming  condition.  Any  reduction  in 
the  number  of  detections  required  by  the  algorithm  greatly  increases  its  rate  of  success. 

The  second  goal  was  to  analytically  show  that  the  above  algorithm  is  capable  of 
operating  within  the  DSA  paradigm.  Section  4.1.4  discussed  the  advantages  and 
disadvantages  of  methods  to  interpret  a  hopping  sequence.  The  analysis  of  the  skip,  hold, 
and  modulus  methods  showed  that  Gold’s  algorithm  performs  to  the  same  limitations  as 
the  COD  method  of  rendezvous  for  FHSS  radio  systems. 

The  third  goal  of  this  research  was  to  present  system  hardware  requirements  for  an 
FPGA  implementation  of  Gold’s  algorithm.  Research  into  Gold’s  algorithm  as  shown  in 
Section  4. 1  involved  the  development,  testing,  and  analysis  of  an  FPGA  implementation 
of  the  algorithm  at  different  sequence  period  lengths  (LFSR  bit  length)  and  number  of 
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communication  channels  (tap  bits).  The  experiment  revealed  that  only  a  general  trend 
showing  that  increasing  either  variable  causes  a  decrease  in  maximum  operational  clock 
frequency.  This  clock  limitation  resulted  from  significant  routing  delay  more  than  delay 
due  to  logic.  The  resources  required  to  build  each  system  increase  as  system  complexity 
increased.  Of  the  two  main  reportable  FPGA  resources,  registers  and  LUTs,  a  general 
equation  was  determined  to  predict  the  number  of  registers  required.  The  LUT  usage  of 
the  system  did  not  conform  to  a  predictable  pattern  with  reliable  results.  The  hypothesis 
was  disproved  in  that  all  resources  required  are  not  directly  calculable.  These  results  are 
specific  to  synthesis  using  Xilinx  ISE  13.2  and  the  XST  synthesis  tool  targeted  to  the 
Virtex-5  FPGA. 

The  last  goal  of  this  research  was  to  evaluate  the  performance  expectations  of  three 
communication  methods  for  exchanging  radio  environment  data  on  a  multi-nodal  radio 
network  via  simulation.  The  OPNET  simulation  experiment  revealed  that  both  the  Polling 
and  Time-Division  protocols  required  less  overhead  costs  to  average  network  throughput 
at  small  sized  networks.  These  protocols  maintained  above  90%  maximum  throughput 
upto  a  network  size  of  approximately  35  nodes  when  the  a  REM  exchange  occurred  every 
1  second.  As  network  size  increases,  the  Priority  protocol  performed  the  best  method  of 
the  three  tested  under  near  real-world  scenarios.  The  Real  World  scenario  used  in  testing 
never  met  the  90%  threshold;  however,  extrapolation  of  trends  show  that  any  increase  in 
network  size  above  the  levels  tested  should  meet  the  threshold.  The  experiment  also 
showed  that  the  addition  of  nodes  to  a  static  network  where  all  nodes  are  within 
communication  range  did  not  increase  overhead  costs  in  larger  networks  when  using  the 
Priority  protocol.  These  results  match  that  of  the  hypothesis.  Each  REM  exchange 
protocol  displayed  points  of  advantage  and  disadvantage  as  network  traffic  and  network 
size  increase.  No  protocol  performed  best  over  all  tests,  and  therefore  the  selection  of  the 
exchange  protocol  becomes  a  factor  within  a  cognitive  system. 
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5.2  Research  Contributions 


This  research  provides  two  distinct  contributions  to  the  study  of  DSA,  and  therefore 
the  field  of  CR.  First,  this  research  establishes  Gold’s  algorithm  as  a  valid  rendezvous 
method  for  Frequency  Hopping  DSA  networks.  Compared  to  traditional  methods  such  as 
COD,  Gold’s  algorithm  reduces  rendezvous  time  when  higher  hop  rates  are  required  or 
significant  time  has  elapsed  since  the  key  was  issued.  Additionally,  this  research  offers  the 
first  FPGA  hardware  implementation  of  Gold’s  algorithm  providing  timing  and  resource 
requirements  for  radio  designers. 

Second,  this  research  demonstrates  the  impact  to  network  performance  for  three 
exchange  protocols  when  radio  channel  availability  data  must  be  exchanged  as  part  of 
DSA  operations.  Examination  of  metrics  such  as  data  throughput,  delay,  and  data  drop 
rates  provide  an  estimation  of  network  performance  with  varying  network  size  under 
different  network  non-control  traffic  workloads.  Furthermore,  a  simulation  test  scenario  to 
estimate  real-world  conditions  is  presented  due  to  the  lack  of  actual  real-world 
representative  test  sets. 

Two  OPNET  nodal  models  were  developed  to  compare  the  exchange  protocols. 
Utilization  of  these  models  provide  future  researchers  with  advanced  capabilities  not 
currently  available.  Therefore,  these  models  can  be  considered  minor  contributions.  The 
first  model  expands  the  features  of  the  IEEE  802.11b  OPNET  wireless  model  to 
incorporate  the  transmission  technique  of  FHSS.  OPNET’s  model  provides  frequency 
hopping  as  a  function  option,  but  the  feature  was  never  implemented  in  the  model.  The 
improved  model  is  currently  restricted  to  slow-hopping  operations.  The  second  model 
modifies  the  PCF  of  IEEE  802.11b  within  the  MAC  process  model.  This  modification 
allows  PCF  operation  without  the  need  of  a  dedicated  access  point,  and  leverages  the  PCF 
operation  for  transfer  of  radio  environment  data  only. 
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5.3  Future  Work 


One  of  the  most  difficult  problems  developing  this  research  was  the  lack  of 
environmental  RF  data  to  be  used  for  experimentation.  No  open  source  data  sets  were 
discovered  to  create  a  real-world  operation  simulation,  and  therefore  a  representative 
scenario  had  to  be  created.  One  suggestion  for  future  work  includes  the  collection  and 
analysis  of  the  RF  environment  to  create  a  test  set.  This  work  would  provide  researchers 
with  realistic  conditions  for  testing.  It  also  could  lead  to  studies  in  environment  prediction 
algorithms.  Secondly,  the  simulations  performed  within  this  research  were  limited  to 
stationary  nodal  models  within  communication  range.  Future  research  into  the  affects  that 
mobility  could  cause  in  the  exchange  process  is  needed.  Additionally,  the  inclusion  of 
existing  routing  protocols  and  application  layer  simulation  would  further  the  study  of 
reliability  in  a  cognitive  network. 

Although  network  simulations  provide  needed  insight  into  wireless  network 
performance,  hardware  implementation  and  testing  is  the  ultimate  goal.  The  custom  IP 
core  for  Gold’s  algorithm  needs  to  be  transitioned  to  an  RF  capable  platform  for  further 
testing.  The  exchange  protocols  researched  in  this  paper  may  also  be  implemented  on  a 
development  board  for  further  testing.  AFIT  is  dedicated  to  developing  a  physical 
cognitive  radio  capable  of  dynamically  selecting  rendezvous  methods,  routing  protocols, 
and  transmission  waveforms  to  optimize  performance.  Each  of  these  areas  should  be 
explored  and  possibly  implemented. 

Continuing  research  into  cognitive  radio  allows  for  better  utilization  of  a  limited 
resource.  Radios  equipped  with  the  ability  to  actively  select  the  best  operating  parameters 
provides  flexible  and  reliable  communication  through  a  increasingly  chaotic  medium.  For 
military  use,  a  cognitive  system  could  make  the  difference  between  a  successful  mission 
and  complete  failure.  Future  research  by  AFIT  will  assist  in  advancing  our 
communication  technology  for  a  stronger  United  States  of  America. 
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Appendix:  Experimental  Results 


A.l  FPGA  implementation  Results 


Figure  A.  1 :  FPGA  Device  Utilzation  Summary  and  HDL  Synthesis  Report 
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Figure  A. 2:  FPGA  Advanced  HDL  Synthesis  Report  and  Final  Report 
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Figure  A. 3:  Baseline  Throughput 


2000 


2500 


77 


Average  Retry  Attempts(packets)  Avg  Drop  Rate  (bits/sec) 


xio5  baseline  Average  Data  Throughput,  4  Nodes 

8  r 


*0  20  40  60  80  100  120  140  160 

Interarrival  Rate  (msec) 

Figure  A.4:  N4  Data  Throughput 


N=4,beac=none 
N=4,  degraded 


baseline  Average  Drop  due  to  Retry,  4  Nodes 
50 

40 

30 

20 

10 

0 


<:  o 


baseline  Average  Drop  due  to  Buffer,  4  Nodes 


100  20  40  60  80  100  120  140  160 

Interarrival  Rate  (msec) 

Figure  A. 5:  N4  Retry  Dropped  Data 


20  20  40  60  80  100  120  140  160 

Interarrival  Rate  (msec) 

Figure  A. 6:  N4  Buffer  Dropped  Data 


1.35 


baseline  Average  Retry  Attempts,  4  Nodes 


0.3 

1.25 

0.2 

1.15 

0.1 

1.05 


20  40  60  80  100  120  140  160 


1.5 


3  05 


0 


0 


baseline  Average  Delay,  4  Nodes 

\ 

\ 

\ 

\ 

\ 

\ 

\ 

\ 

v 

i 

i 

i 

i 

t 

i 

t 

i 

i 

t 

i 

i 

i 

i 

i 

i 

20  40  60  80  100  120  140  160 


Interarrival  Rate  (msec) 

Figure  A. 7:  N4  Retry  Attempts 


Interarrival  Rate  (msec) 
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Figure  A. 9:  N9  Data  Throughput 
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Figure  A.  10:  N9  Retry  Dropped  Data 
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Figure  A.  14:  N16  Data  Throughput 
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Figure  A. 19:  N25  Data  Throughput 
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Figure  A. 20:  N25  Retry  Dropped  Data 
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Figure  A. 23:  N25  Packet  Delay 
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Figure  A. 24:  N36  Data  Throughput 
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Figure  A. 26:  N36  Buffer  Dropped  Data 
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Figure  A. 27:  N36  Retry  Attempts 
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Figure  A. 29:  N49  Data  Throughput 
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Figure  A. 30:  N49  Retry  Dropped  Data 
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Figure  A.31:  N49  Buffer  Dropped  Data 
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Figure  A. 32:  N49  Retry  Attempts 


12 


baseline  Average  Delay,  49  Nodes 


10 


Q  4 

60 

<i  2 


-2 


700  750  800  850  900  950  1000  1050  1100  1150 


Interarrival  Rate  (msec) 

Figure  A. 33:  N49  Packet  Delay 
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Figure  A. 34:  N64  Data  Throughput 


xlO4 

3 


2.5 
2 

1.5 
1 

0.5 

0 

-0.5 


baseline  Average  Drop  due  to  Retry,  64  Nodes 


xlO4 

15 


10 


%■ 

tH 

Q 

W)  0 


baseline  Average  Drop  due  to  Buffer,  64  Nodes 

1 


800  1000  1200  1400  1600 

Interarrival  Rate  (msec) 


1800  2000 


800  1000 


1200  1400  1600 

Interarrival  Rate  (msec) 


1800  2000 


Figure  A. 35:  N64  Retry  Dropped  Data 
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Figure  A. 37:  N64  Retry  Attempts 


800  1000  1200  1400  1600  1800  2000 

Interarrival  Rate  (msec) 

Figure  A.38:  N64  Packet  Delay 
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Figure  A. 39:  N81  Data  Throughput 
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Figure  A.40:  N81  Retry  Dropped  Data 
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Figure  A. 41:  N81  Buffer  Dropped  Data 
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Figure  A.42:  N81  Retry  Attempts 
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Figure  A.43:  N81  Packet  Delay 
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Figure  A.44:  N100  Data  Throughput 
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Figure  A. 45:  N100  Retry  Dropped  Data 
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Figure  A. 50:  N4  Retry  Dropped  Data 
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Figure  A. 53:  N4  Packet  Delay 
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Figure  A. 55:  N9  Retry  Dropped  Data 
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Figure  A. 57:  N9  Retry  Attempts 
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Figure  A. 56:  N9  Buffer  Dropped  Data 
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Figure  A. 58:  N9  Packet  Delay 
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Figure  A. 59:  N16  Data  Throughput 
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Figure  A. 60:  N16  Retry  Dropped  Data 
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Figure  A.61:  N16  Buffer  Dropped  Data 
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Figure  A. 62:  N16  Retry  Attempts 
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Figure  A. 63:  N16  Packet  Delay 
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Figure  A. 64:  N25  Data  Throughput 
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Figure  A. 65:  N25  Retry  Dropped  Data 
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Figure  A. 66:  N25  Buffer  Dropped  Data 
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Figure  A. 69:  N36  Data  Throughput 
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Figure  A.70:  N36  Retry  Dropped  Data 
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Figure  A.71:  N36  Buffer  Dropped  Data 
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Figure  A.73:  N36  Packet  Delay 
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Figure  A.74:  N49  Data  Throughput 
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Figure  A.75:  N49  Retry  Dropped  Data 


Polling  Average  Retry  Attempts,  49  Nodes 

1.6 


700  750  800  850  900  950  1000  1050  1100  1150 
Interarrival  Rate  (msec) 
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Figure  A. 76:  N49  Buffer  Dropped  Data 
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Figure  A.78:  N49  Packet  Delay 


92 


Average  Retry  Attempts(packets)  Avg  Drop  Rate  (bits/sec) 


xio5  Polling  Average  Data  Throughput,  64  Nodes 


Figure  A. 79:  N64  Data  Throughput 
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Figure  A. 80:  N64  Retry  Dropped  Data 
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Figure  A.81:  N64  Buffer  Dropped  Data 
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Figure  A. 83:  N64  Packet  Delay 
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Figure  A. 84:  N81  Data  Throughput 
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Figure  A. 85:  N81  Retry  Dropped  Data 
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Figure  A. 88:  N81  Packet  Delay 
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Figure  A. 89:  N100  Data  Throughput 
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7igure  A. 90:  N100  Retry  Dropped  Data 
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Figure  A. 93:  N100  Packet  Delay 
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Figure  A. 94:  N4  Data  Throughput 
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Figure  A. 95:  N4  Retry  Dropped  Data 
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Figure  A. 96:  N4  Buffer  Dropped  Data 


Interarrival  Rate  (msec) 

Figure  A. 97:  N4  Retry  Attempts 


Interarrival  Rate  (msec) 

Figure  A. 98:  N4  Packet  Delay 
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Figure  A. 99:  N9  Data  Throughput 
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Figure  A.  102:  N9  Retry  Attempts 
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Figure  A.  100:  N9  Retry  Dropped  Data 
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Figure  A.  101:  N9  Buffer  Dropped  Data 
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Figure  A.  103:  N9  Packet  Delay 
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Figure  A.  104:  N16  Data  Throughput 
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Figure  A.  107:  N16  Retry  Attempts 
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Figure  A.  108:  N16  Packet  Delay 


98 


Average  Retry  Attempts(packets)  ,  Avg  Drop  Rate  (bits/sec) 


xio5  Time  Division  Average  Data  Throughput,  25  Nodes 


N=25,beac=none 

N=25,beac=0.25 

N=25,beac=0.5 

N=25,beac=0.75 

N=25,beac=l 

N=25,  degraded 


3.5  - ■ - 1 - 1 - 1 - 1 - 1 - ' 

320  340  360  380  400  420  440  460 

Interarrival  Rate  (msec) 

Figure  A.  109:  N25  Data  Throughput 
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Figure  A.  112:  N25  Retry  Attempts 
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Figure  A.l  13:  N25  Packet  Delay 


99 


Average  Retry  Attempts(packets)  l  ^vg  Drop  Rate  (bits/sec) 


Interarrival  Rate  (msec) 

Figure  A.l  14:  N36  Data  Throughput 
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Figure  A.l  16:  N36  Buffer  Dropped  Data 
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Figure  A.  117:  N36  Retry  Attempts 
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Figure  A.l  19:  N49  Data  Throughput 
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Figure  A.  120:  N49  Retry  Dropped  Data 
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Figure  A.  121:  N49  Buffer  Dropped  Data 
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Figure  A.  123:  N49  Packet  Delay 
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Figure  A.  124:  N64  Data  Throughput 


N =64,beac=none 

N=64,beac=0.5 

N=64,beac=l 

N=64,beac=1.5 

N=64,beac=2 

N=64,  degraded 


xlO4  Time  Division  Average  Drop  due  to  Retry,  64  Nodes 


-0.5 - ■ - ■ - ■ - ■ - ■ - ■ 

800  1000  1200  1400  1600  1800  2000 

Interarrival  Rate  (msec) 

Figure  A.  125:  N64  Retry  Dropped  Data 
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Figure  A.  127:  N64  Retry  Attempts 
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Figure  A.  126:  N64  Buffer  Dropped  Data 
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Figure  A.  128:  N64  Packet  Delay 
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Figure  A.  129:  N81  Data  Throughput 
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ugure  A.  130:  N81  Retry  Dropped  Data 
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Figure  A. 131:  N81  Buffer  Dropped  Data 
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Figure  A.  133:  N81  Packet  Delay 
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Figure  A.  134:  N100  Data  Throughput 
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Figure  A.  199:  N25  Data  Throughput 
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Figure  A. 204:  N36  Data  Throughput 
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Figure  A. 209:  N49  Data  Throughput 
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Figure  A.214:  N64  Data  Throughput 
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Figure  A.217:  N64  Retry  Attempts 
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Figure  A.215:  N64  Retry  Dropped  Data 


-0.5 


800  1000  1200  1400  1600  1800  2000 

Interarrival  Rate  (msec) 

Figure  A.216:  N64  Buffer  Dropped  Data 

Priority-Identical  Average  Delay,  64  Nodes 
30 

25  1 

^  20 
O 
CD 

!15 

Q  10 

bO 

^  5 

— L 


0 

“5800  1000  1200  1400  1600  1800  2000 

Interarrival  Rate  (msec) 
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120 


Average  Retry  Attempts(packets)  Avg  Drop  Rate  (bits/sec) 


xio5  Priority-Identical  Average  Data  Throughput,  81  Nodes 


Figure  A. 219:  N81  Data  Throughput 
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Figure  A. 222:  N81  Retry  Attempts 
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Figure  A. 223:  N81  Packet  Delay 
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xio5  Priority-Identical  Average  Data  Throughput,  100  Nodes 


Figure  A. 224:  N100  Data  Throughput 
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igure  A. 225:  N100  Retry  Dropped  Data 
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Figure  A. 226:  N100  Buffer  Dropped  Data 
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Figure  A. 227:  N100  Retry  Attempts 
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Figure  A. 229:  N4  Data  Throughput 
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Figure  A. 230:  N4  Retry  Dropped  Data 
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Figure  A.231:  N4  Buffer  Dropped  Data 
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Figure  A. 234:  N9  Data  Throughput 
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Figure  A. 241:  N16  Buffer  Dropped  Data 
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Figure  A. 243:  N16  Packet  Delay 
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Figure  A. 249:  N36  Data  Throughput 
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Figure  A.252:  N36  Retry  Attempts 
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Figure  A. 254:  N49  Data  Throughput 
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Figure  A. 256:  N49  Buffer  Dropped  Data 
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Figure  A. 258:  N49  Packet  Delay 
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Figure  A. 259:  N64  Data  Throughput 
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Figure  A. 260:  N64  Retry  Dropped  Data 
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Figure  A. 261:  N64  Buffer  Dropped  Data 
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Figure  A. 263:  N64  Packet  Delay 


I 

i 


129 


Average  Retry  Attempts(packets)  Avg  Drop  Rate  (bits/sec) 


xio5  Priority-Random  Average  Data  Throughput,  81  Nodes 


Figure  A. 264:  N81  Data  Throughput 
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Figure  A. 268:  N81  Packet  Delay 
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xio5  Priority-Random  Average  Data  Throughput,  100  Nodes 


Figure  A. 269:  N100  Data  Throughput 
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Figure  A.271:  N100  Buffer  Dropped  Data 
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A. 5.4  Real  World  Scenario. 
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Figure  A. 274:  N4  Data  Throughput 
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Figure  A. 277:  N4  Retry  Attempts 
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Figure  A. 275:  N4  Retry  Dropped  Data 
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Figure  A. 276:  N4  Buffer  Dropped  Data 
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xlO5  Priority-RealWorld  Average  Data  Throughput,  9  Nodes 
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Figure  A. 279:  N9  Data  Throughput 
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Figure  A. 280:  N9  Retry  Dropped  Data 
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Figure  A. 282:  N9  Retry  Attempts 
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Figure  A.281:  N9  Buffer  Dropped  Data 
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Figure  A. 283:  N9  Packet  Delay 
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xlO5  Priority-RealWorld  Average  Data  Throughput,  16  Nodes 
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Figure  A. 284:  N16  Data  Throughput 
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Figure  A. 286:  N16  Buffer  Dropped  Data 
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Figure  A. 288:  N16  Packet  Delay 
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Figure  A. 289:  N25  Data  Throughput 
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Figure  A. 293:  N25  Packet  Delay 
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xio5  Priority-RealWorld  Average  Data  Throughput,  36  Nodes 
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Figure  A. 294:  N36  Data  Throughput 


x  l(^iority-Real World  Average  Drop  due  to  Buffer,  36  Nodes 
4 


O  3 

ni  u 


Q 

60 

3  0 


-1 


,  \  “t-I 


450  500  550  600  650  700  750  800  850 

Interarrival  Rate  (msec) 

Figure  A. 296:  N36  Buffer  Dropped  Data 
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Figure  A. 298:  N36  Packet  Delay 
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xio5  Priority-RealWorld  Average  Data  Throughput,  49  Nodes 


Figure  A. 299:  N49  Data  Throughput 
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Figure  A. 301:  N49  Buffer  Dropped  Data 
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Figure  A. 303:  N49  Packet  Delay 


137 


xio5  Priority-RealWorld  Average  Data  Throughput,  64  Nodes 


Figure  A. 304:  N64  Data  Throughput 


N=64,beac=none 

N=64,beac=0.5 

N=64,beac=l 

N=64,beac=1.5 

N=64,beac=2 

N=64,  degraded 


X 1  ((Priority  RealWorld  Average  Drop  due  to  Retry,  64  Nodes 
3  r 


2.5 
2 

1.5 
1 


Interarrival  Rate  (msec) 
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xio5  Priority-RealWorld  Average  Data  Throughput,  81  Nodes 


Figure  A. 309:  N81  Data  Throughput 
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Figure  A. 311:  N81  Buffer  Dropped  Data 
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Figure  A.317:  N100  Retry  Attempts 


xl^iority-Real World  Average  Drop  due  to  Buffer,  100  Nodes 
20 


o  15 


10 


OS 

o- 


1500  1600  1700  1800  1900  2000  2100  2200 

Interarrival  Rate  (msec) 

Figure  A. 316:  N100  Buffer  Dropped  Data 


Interarrival  Rate  (msec) 

Figure  A.318:  N100  Packet  Delay 


140 


Appendix:  Gold’s  algorithm 


B.l  Theory  and  Example 

Gold’s  algorithm  is  based  on  the  properties  of  a  LFSR  pseudorandom  number 
generator  (PRNG).  The  LFSR  consists  of  a  linear  shift  register  of  length  N,  frequency 
taps,  and  feedback  taps.  The  number  of  frequencies  taps  is  based  on  the  number  of 
frequency  possibilities  that  the  generator  is  to  produce  (i.e.  for  32  frequencies,  log2 32  =  5, 
so  5  frequency  taps  are  required).  The  feedback  taps  are  used  to  create  the  feedback 
polynomial  or  reciprocal  characteristic  polynomial.  The  arrangement  of  taps  for  feedback 
in  an  LFSR  can  be  expressed  arithmetically  as  a  polynomial  modulo  2.  This  means  that 
the  coefficients  of  the  polynomial  must  be  Is  or  Os.  This  arrangement  allows  for  the 
creation  of  the  pseudorandom  nature  of  the  generator.  The  selection  of  tap  points  has  been 
well  studied  and  is  out  of  the  scope  of  this  project.  It  should  be  noted  that  the  selection  of 
the  feedback  taps  directly  impacts  the  period  of  the  sequence. 

Gold’s  algorithm  utilizes  the  linear  relationship  of  the  feedback  and  frequency  taps. 
The  algorithm  executes  three  key  functions  to  join  an  existing,  transmitting  system:  1) 
determination  of  a  initial  vector  state  for  the  receiver’s  LFSR;  2)  determination  of  the 
register  bits  to  use  as  frequency  taps;  and  3)  recreation  of  and  synchronization  with  the 
transmitting  system’s  sequence. 

To  best  understand  the  operation  of  Gold’s  algorithm,  an  example  is  used.  The 
example  was  provided  in  the  final  report  of  the  SIBR  contract  [28].  Understanding  the 
operation  of  the  algorithm  is  vital  for  VHDL  implementation.  The  transmitter,  or  source, 
utilizes  a  10-bit  LFSR  represented  by  Figure  B.L  First,  examine  the  changes  in  the  LFSR 

over  time.  Let  the  LFSR  be  described  by  a,  a  vector  representing  the  feedback  taps,  and  Zj, 
the  state  of  the  LFSR  at  time  slot  i.  The  required  a  priori  knowledge  of  a  is  a  limitation  to 
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Figure  B.l:  Example  Source  LFSR  PRNG 


the  algorithm. 


a 


a  i  ci  2  ...  ci  10 


For  the  example, 


I  Zi  Zi+ 1  ...  Zi+ 9 


a  =  1  1101  10100 


(B.l) 


With  this  knowledge  of  a,  a  transition  matrix  can  be  created  for  the  FFSR  such  that 

000000000  a\ 
100000000  a2 
010000000  a3 
001000000  a4 
000100000  a5 
000010000  cie 
000001000  a-j 
000000100  a8 
000000010 
0  0  0  0  0  0  0  0  1  cfio 

This  transition  matrix  is  used  to  calculate  the  next  state  of  the  shift  register,  ziH  ], 
given  Zi.  This  can  be  shown  by 


Z\  Z2 


ZlO 


x  A 


Zi  Z3  ...  Z 11 


(B.2) 
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where  A  is  the  transition  matrix.  Additionally,  it  can  be  shown  that  any  future  register  state 
can  be  calculated  by  using  a  known  register  state  and  the  associative  property  of  matrices. 

z;+2  =  z,-+i  x  A  =  z,-  x  A  x  A  =  z;  x  A2  (B.3) 

or  zt  =  z0  x  A'  where  zr  is  the  desired  state,  z0  is  the  original  state,  and  t  is  the  number  of 
time  slots  between  the  occurrence  of  the  two  states. 

Gold’s  algorithm  functions  by  looking  at  the  time  of  arrival  of  a  single  critical 
frequency  by  a  receiver.  By  recording  the  time  occurrences,  a  deterministic  system  can  be 
created.  For  the  example  problem,  the  transmitter  would  create  sequence 
101100110111111111 10001 10001  at  the  two  frequency  taps.  Let  frequency  1 1  be  the 
critical  frequency  of  interest,  and  let  the  first  instance  of  the  critical  frequency  occur  at 
t  =  0.  Therefore,  in  the  above  sequence  the  critical  frequency  occurs  at 
t  =  0, 4, 7,  8, 9, 10, 11,12, 13, 14, 15.  Let  these  occurrences  of  the  critical  frequency  be 
referenced  as  set  Tn. 

Then  the  matrices  of  interest  are  A7"  =  {a0,  A4,  A7,  A8,  A9,A10,  A11,  A12,  A13,  A14,  A15}. 
Note  the  algorithm  requires  N+l  occurrences  of  the  critical  frequency  where  N  is  the 
length  of  the  LFSR. 

The  linear  relationship  between  tap  points  on  the  source  allows  for  another 
observation.  Since  the  LFSR  continues  to  shift  the  state  left,  a  frequency  tap  of  bit  4  and 
bit  5  is  equivalent  the  taps  being  located  at  bits  1  and  2.  In  general,  only  the  space  relation 
between  the  frequency  taps  is  critical,  and  as  such  the  first  tap  can  always  be  placed  on  bit 
1  for  the  receiver.  This  aspect  of  recreating  the  LFSR  solution  allows  us  to  show  that  all  z, 
share  z\  for  the  occurrences  listed  above. 

(zi  Z2  ...  z10)  x  Ar"(l)  =  z\  (B.4) 

where  ATn(  1)  is  the  first  column  of  matrix  A 7"  and  the  vector  z  is  state  of  the  LFSR  at  /  =  0 
(the  first  occurrence  of  the  critical  frequency). 
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Going  back  to  the  example,  see  that: 
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By  collecting  these  columns  together,  the  following  equation  emerges. 
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(B.6) 


A  transposition  of  the  equation  yields  a  system  of  equations  to  create  the  solution 


space. 
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To  solve  the  system  of  equations,  binary  row  reduction  is  used  to  obtain  the  canonical 


form. 
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which  equates  to  [zuZ2,Zi,ZA,Z5,Z6,Zi,Zs,Z9,Z\d\  = 


[Z5,Z4  +  Z5,0,  Z4,  Z5,  Z4,  Z5,  Z4,  Z5,  Z5,  Z5] 


(B.8) 


Note  that  the  solution  space  depends  on  two  variables,  Z4  and  z5.  The  n  independent 
variables  are  directly  related  to  the  use  of  n  frequency  taps  where  n  =  2  in  this  example. 
Manipulating  these  variables  creates  the  vector  space  of  candidate  solutions  shown  in 
Table  B.l. 
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Table  B.l:  Vector  Space  of  Candidate  Solutions 
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An  all-zero  solution  is  not  a  satisfactory  solution  since  it  always  provides  a  feedback 
of  zero;  therefore,  only  three  possible  solutions  exist.  Next,  the  algorithm  identifies  any 
shift  relationships  among  the  solution  candidates  to  determine  which  of  the  solutions  is 
the  unique  solution. 

Examining  shift  relationships  shows  that  solution  (1, 0, 0, 1, 1, 0, 1, 1, 1, 1)  is  same  as 
the  single  left  shift  of  (1, 1, 0, 0, 1, 1, 0, 1, 1, 1).  To  find  the  unique  solution,  this  method  of 
shift  comparison  requires  that  n  solutions  (the  same  as  the  necessary  number  of  taps)  be 
found  within  a  single  candidate  vector.  In  this  case,  (1, 1, 0, 0, 1, 1, 0, 1, 1, 1)  has  proven 
that  itself  and  one  other  solution  are  contained  within  it,  and  therefore  must  be  the  unique 
solution. 

Additionally,  the  number  of  shifts  required  to  create  the  other  candidate  solutions 
indicates  the  frequency  tap  points.  Specifically,  the  first  bit  in  the  unique  solution  is  a 
frequency  tap  since  the  unique  solution  matches  itself.  The  second  solution  is  created  by 
one  shift;  therefore,  the  second  bit  is  also  a  frequency  tap. 

Through  these  calculations,  two  of  the  three  functions  of  the  algorithm  have  been 
achieved:  1)  determination  of  an  initial  vector  state  for  the  LFSR;  2)  determination  of  the 
register  bits  to  use  as  frequency  taps.  The  third  function,  recreation  of  and  synchronization 
with  the  transmitting  system’s  sequence,  only  requires  loading  the  LFSR  with  the 
calculated  initial  value  and  stepping  through  the  same  number  of  frequency  changes  that 
the  source  progressed  through  since  the  first  occurrence  was  recorded. 

B.2  VHDL  Implementation 

The  hardware  implementation  consists  of  a  16-bit  length  LSFR  with  5  feedback  taps 
and  5  frequency  taps.  As  such,  the  PRNG  will  generate  a  sequence  spanning  32 
frequencies  according  to  a  near  uniform  distribution.  The  register  length  and  selection 
feedback  tap  locations  determine  the  period  of  a  repeating  pattern  with  in  the  sequence. 
The  maximum  period  for  a  16-bit  LSFR  is  65,535  cycles.  Gold’s  algorithm,  as  written  in 
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VHDL,  consists  of  seven  distinct  computation  processes,  or  blocks,  and  a  top-level 
wrapper  used  for  component  coordination  and  control.  This  code  comprises  the  custom  IP 
core  used  in  this  research  effort.  The  design  requires  as  inputs:  one  clock  operating  at  the 
same  rate  which  the  transmitter  is  changing  frequencies;  one  higher  rate  clock  constrained 
by  timing  requirements  of  the  hardware  implementation;  a  critical  frequency  detection 
core;  and  software  registers  to  control  initial  values  and  an  asynchronous  reset.  Figure  B.2 
shows  a  graphical  representation  of  the  Gold’s  algorithm  custom  IP  core  broken  into 
processing  blocks. 


Figure  B.2:  Gold’s  algorithm  custom  IP  core 


B.2.1  Top-level. 

The  top-level  wrapper  coordinates  block  communication  and  provides  control  logic 
for  operations.  First,  the  system  determines  when  the  critical  frequency  occurs.  A 
combination  of  a  Xilinx  FFT  IP  core  and  a  simple  signal  comparison  accomplishes  this 
task.  When  the  frequency  designated  as  the  critical  frequency  is  detected,  the  comparison 
produces  a  trigger  which  is  used  by  Block  2,  as  described  in  Section  B.2. 3  Two  resets  exist 
for  the  system,  a  software  register  commanded  reset  and  a  hardware  reset  from  Block  5. 

The  controls  incorporated  into  the  top-level  wrapper  primarily  operate  to  allow  the 
system  to  correctly  synchronize  after  a  solution  has  been  found.  Since  the  system  works 
by  calculating  the  LFSR  at  the  first  occurrence  of  the  critical  frequency,  the  number  of 
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frequency  changes  beyond  this  t  =  0  must  be  tracked.  A  counter  (referred  to  as  the 
primary  counter)  tracks  these  changes.  Once  the  system  determines  a  unique  solution,  it 
must  progress  through  the  same  number  of  changes  as  the  transmitter.  The  use  of  a  second 
counter  tracks  the  LFSR  changes  in  the  receiver.  Lastly,  a  comparator  determines  when 
the  two  counters  match.  This  comparator  serves  as  a  synchronization  indicator. 
Additionally,  this  synchronization  indicator  determines  the  clock  rate  used  in  Block  6,  as 
described  in  Section  B.2.6 

B.2.2  Block  1:  Matrix  power  multiplication. 

Block  1  of  the  VHDL  code  implements  the  transformation  matrix  multiplication  once 
for  every  rising  edge  of  the  frequency  change  clock.  The  transition  matrix  is  created  using 
an  input  vector  for  a,  as  in  Equation  B.l.  This  vector  loads  from  a  software  register 
allowing  for  quick  adaptation.  An  intermediate  matrix  is  stored  each  clock  cycle,  and  is 
subject  to  a  system  reset  input.  Block  1  outputs  a  vector  containing  the  first  column  of  the 
calculated  matrix  as  shown  in  Equation  B.5.  This  vector  is  used  by  Block  2.  Block  1 
executes  in  1  cycle. 

B.2.3  Block  2:  Collection  and  transposition. 

Block  2  collects  the  column  vectors  from  Block  1  when  a  critical  frequency  is 
detected.  The  frequency  detection  signal  is  externally  triggered  by  an  FFT.  As  this  block 
latches  the  column  vector  from  Block  1,  it  also  performs  the  transpose  operation 
converting  each  column  into  a  row,  and  combining  the  rows  into  a  square  matrix  which  is 
the  output  of  the  block.  This  operation  produces  results  similar  to  Equation  B.7.  Once 
Block  2  detects  and  collects  N  +  1  vectors,  it  triggers  a  finish  flag  to  initiate  Block  3. 
Block  2  executes  in  1  cycle. 

B.2.4  Block  3:  Matrix  reduction. 

Block  3  preforms  a  binary  row  echelon  matrix  reduction  on  the  matrix  from  Block  2. 
Since  the  matrix  reduction  process  depends  on  the  only  the  completion  of  Block  2,  a  faster 
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clock  rate  can  be  utilized.  The  faster  clock  rate  is  used  on  all  further  blocks  in  the  system. 
The  reduction  process  uses  a  7  state  finite  state  machine  (FSM)  design.  The  output  is  a 
row  echelon  reduced  matrix  similar  to  Equation  B.8 

State  0  is  used  as  an  initial  load  state,  and  is  only  used  upon  block  initialization. 

State  1  is  used  to  detect  the  first  occurrence  of  a  1  in  the  first  column  of  the  matrix. 
The  first  entry  (upper  right  of  matrix)  is  examined  to  determine  if  it  is  a  1.  If  it  is  a  1  and 
another  1  had  not  already  been  found,  the  entire  row  is  stored  as  a  temporary  signal  vector. 
The  stage  will  then  rotate  the  whole  matrix  by  one  row  (i.e.  the  first  row  is  shifted  to  the 
bottom  and  row  2  is  moved  to  row  1).  This  rotation  occurs  for  each  row  whether  nor  not 
the  row  was  selected  as  the  temporary  signal  vector.  Therefore,  State  1  requires  N  cycles 
to  complete.  After  the  completion  of  State  1,  the  hardware  transitions  to  State  2. 

State  2  is  similar  to  State  1  in  that  it  rotates  through  each  row  detecting  when  a  1 
occurs  in  at  the  first  entry  of  the  matrix.  The  difference  occur  in  the  operation  after 
detection.  If  a  row  is  detected  to  have  a  left  most  1  then  the  row  is  compared  to  the 
temporary  signal  vector.  This  test  eliminates  the  ability  to  manipulate  the  row  with  the 
first  1  occurrence.  Other  rows  that  contain  a  1  will  undergo  a  bitwise  xor  operation 
between  that  row  and  the  temporary  signal  vector.  This  serves  to  eliminate  all  but  the  first 
1  in  the  first  column  of  the  matrix.  State  2  requires  N  cycles  to  complete.  After  the 
completion  of  State  2,  the  hardware  transitions  to  State  3. 

State  3  performs  a  row  swap  operation  on  the  matrix.  The  operation  swaps  the  row 
that  had  the  first  1  occurrence  from  Stage  1  with  the  top  row.  This  stage  requires  1  cycle  to 
complete. 

State  4  rotates  the  matrix  one  more  time  by  moving  the  top  row  to  the  bottom  of  the 
matrix,  and  all  other  rows  up  by  one.  This  stage  requires  1  cycle  to  complete. 

State  5  performs  a  matrix  left  rotate  operation.  Each  row  is  individually  rotated  such 
that  its  first  bit  becomes  its  last  bit  while  all  other  bits  shift  left  by  one  position.  Stage  5 
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will  run  N  times  so  that  each  column  is  examined  by  states  1  through  4.  Therefore,  if  the 
stage  has  executed  less  than  N  times  the  state  is  reset  to  state  1.  Otherwise,  the  state  is 
progressed  to  State  6.  Each  execution  of  Stage  5  requires  1  cycle,  but  also  controls  the 
re-execution  of  previous  states. 

State  6,  the  last  state  in  the  block  latches  the  result  from  the  intermediate  matrix  to 
the  output  matrix  to  be  used  by  the  next  block.  It  also  sets  a  finish  flag  to  initiate  Block  4 
to  begin  operations. 

The  total  execution  requirement  of  block  3  is  IN 2  +  3 N  +  2  cycles,  where  N  is  the 
size  of  the  LFSR. 

B.2.5  Blocks  4  and  5:  Solution  solver. 

To  decrease  area  usage  and  take  advantage  of  internal  block  RAM,  blocks  4  &  5  are 
combined  to  form  a  single  component. 

Block  4  preforms  the  matrix  solver  process.  This  block  takes  the  reduced  matrix, 
determines  which  bits  are  the  independent  variable,  and  creates  a  solution  space  based  on 
the  possible  solutions.  The  solving  process  uses  a  four  state  FSM  design. 

State  0  is  used  as  an  initial  load  state,  and  is  only  used  upon  block  initialization. 

State  1  determines  which  bits  are  the  independent  variables.  In  the  matrix,  any  row 
that  contains  all  Os  is  defined  as  an  independent  variable.  As  such,  state  1  performs  a 
comparison  on  each  row.  The  number  of  variables  is  equivalent  to  the  number  of 
frequency  taps.  The  bit  location  of  each  is  tracked  using  a  vector  signal.  State  1  requires 
N  +  1  cycles  to  complete.  The  extra  cycle  presets  signals  to  be  used  in  state  2. 

States  2  and  3  work  in  combination  to  populate  the  solution  space  matrix  based  on 
the  permutations  of  the  independent  variables.  For  each  possible  combination  (i.e.  0001, 
0010,  001 1,  etc.)  of  the  variable  bits  as  determined  by  stage  1,  the  reduced  matrix  is 
evaluated  to  produce  a  candidate  solution  for  the  solution  space.  The  evaluation  utilizes  a 
distinct  combination  of  and  and  xor  operations  in  sequence  for  each  row.  Each  candidate 
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solution  is  loaded  into  the  block  RAM  upon  calculation.  The  all-zero  combination  is 
removed  giving  2-freqtaps  -  1  possible  solutions  in  the  solution  space.  State  2  requires  1  and 
State  3  (N  +  1)  cycles  to  complete  for  each  possible  combination  of  the  variable  bits.  At 
the  end  of  processing  Block  4,  the  candidate  solutions  have  been  determined.  This  results 
in  the  block  RAM  containing  information  similar  to  Table  B .  1 . 

Block  5  evaluates  the  solution  space  to  determines  if  a  unique  solution  exists.  If  a 
unique  solution  cannot  be  identified,  the  block  commands  a  system  reset  to  the  Gold’s 
algorithm  IP  core.  The  unique  solution  solving  process  uses  a  six  state  FSM  design. 

State  4,  a  continuation  from  State  3  in  Block  4,  load  temporary  signals  with  initial 
values,  and  is  only  executed  upon  block  initialization.  For  initialization,  the  state  loads  the 
first  entry  from  block  RAM  to  a  temporary  vector  which  will  be  used  for  comparisons. 
This  temporary  vector  is  updated  throughout  allowing  different  values  to  be  compared. 
State  7  controls  the  value  of  vector  as  needed. 

State  5  compares  the  bits  of  the  temporary  vector  with  each  of  the  other  candidate 
solutions.  The  result  of  each  row’s  comparison  are  tracked  by  a  separate  vector  to  be 
analyzed  in  State  6. 

State  6  uses  the  comparison  result  vector  from  State  5  to  perform  two  actions  upon  a 
detected  match.  First,  each  candidate  solution  when  evaluated  uses  a  counter  to  determine 
if  the  number  of  other  solutions  are  equal  to  the  number  of  frequency  taps.  As  such  the  the 
comparison  vector  indicates  when  to  adds  to  the  counter.  Secondly,  a  position  tracker 
records  which  of  the  other  solutions  was  the  match.  After  the  first  occurrence  of  State  6, 
the  first  candidate  solution  without  any  bit  shifts  has  been  loaded  as  the  temporary  vector 
and  compared  to  the  other  solutions.  The  counter  results  should  indicate  that  the 
temporary  vector  matched  only  itself.  However,  Gold’s  algorithm  requires  each  candidate 
solution  must  compare  left  shifted  versions  of  itself  to  the  other  possible  solutions  too. 

The  shifting  process  is  controlled  in  State  7. 
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State  7  determines  when  the  unique  solution  has  been  found,  and  controls  the  loading 
of  the  temporary  vector  for  further  comparisons.  The  control  state  first  determines  if  any 
of  the  tested  solutions  already  meet  the  requirement  to  be  deemed  unique  (i.e.  contains  x 
number  of  solutions  within  it,  where  x  is  the  number  of  frequency  taps  needed).  If  a 
solution  has  not  been  identified,  the  temporary  vector  is  updated.  Two  conditions  exist  for 
updating  the  vector.  First,  as  stated,  each  solution  must  compare  several  left  shifted 
versions  of  itself  to  the  other  possible  solutions.  Each  solution  can  be  used  to  create  N 
possible  shifted  versions.  A  shift  is  created  by  using  the  known  feedback  information  the 
currently  value  to  determine  the  need  an  extension  bit.  After  each  shifted  version  has  been 
tested  and  it  is  determined  that  the  candidate  solution  is  not  the  unique  solution,  then  the 
temporary  vector  is  updated  with  the  next  candidate  solution  from  the  block  RAM.  After 
each  update  to  the  temporary  vector  the  state  of  the  FSM  is  set  back  to  State  5.  If  the 
controller  determines  a  unique  solution  exists  at  any  time  then  no  other  solutions  are 
tested.  The  discovered  unique  solution  along  with  the  position  vector  for  that  solution  are 
latched  to  outputs  vectors.  The  position  vector  represents  the  bit  locations  that  must  be 
frequency  taps.  The  unique  solution  output  is  directed  to  block  6  while  the  position  vector 
is  routed  to  Block  7. 

State  8  determines  if  the  unique  solution  is  valid.  Error  in  validity  can  occur  if  the 
system  obtained  a  false  positive  or  an  error  in  calculations  occurred.  If  the  solution  is  not 
valid,  the  reset  signal  is  set;  otherwise,  a  finish  signal  initiates  Block  6. 

In  the  worst  case,  a  solution  is  not  detected  and  this  block  must  compare  each 
possible  solution  to  each  possible  shift  location  for  each  solution.  In  this  case,  the  block 
requires  a  total  of  N  *  (2^reqtaps  -  1)  *  (2^reqtaps  +  1)  +  3  cycles  to  complete. 

B.2.6  Block  6:  PN  Sequencer. 

Block  6  populates  the  PRNG  which  will  recreate  the  sequence  used  by  the 
transmitter.  As  stated,  Block  5  determined  the  unique  solution.  This  unique  solution 
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represents  the  LFSR’s  value  at  t  =  0  or  when  the  first  occurrence  of  the  critical  frequency 
was  detected.  After  the  first  detection,  a  counter  tracks  the  number  of  frequency  changes 
the  transmitter  makes  as  explained  in  Section  B.2.1.  The  block  6  clock  can  operate  at  one 
of  two  frequencies.  A  fast  rate  clock  allows  for  the  generator  to  quickly  process  the 
sequence  until  it  has  executed  the  same  number  of  times  as  the  transmitter  counter  has 
progressed.  When  the  sequences  have  progressed  the  same  number  of  operations,  the  rate 
changes  to  that  of  the  transmitter.  The  output  of  Block  6  is  the  complete  LFSR  value. 

B.2.7  Block  7:  Frequency  Tap. 

Block  7  serves  as  the  final  process  block.  The  block  applies  the  frequency  tap 
locations  determined  in  Block  5  and  applies  them  to  the  register  value  of  the  newly 
generated  sequence  from  Block  6.  Specifically,  each  bit  located  at  the  determined 
frequency  tap  points  are  concatenated  to  create  the  output  vector.  This  vector  provides  the 
frequency  values  to  be  used  by  the  receiver. 
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Appendix:  VHDL  code 


C.l  Gold’s  algorithm  code  wrapper 


library  IEEE; 

use  IEEE.  STD _LOGIC_l  164. ALL; 
use  ieee  .  numeric.std  .  all  ; 


use  work  .  my  .package  .  all  ; 


entity  GOLD.wrapper  is 
PORT  ( FREQ.CLK 
FAST.CLK 
FFT.IN 
ASYNC.RST 
FREQ.OUT 
Master  .Feedback 
catchup.offset 
sy nced.out 


in  STD  .LOGIC ;  —  frequency  change  rate  elk 

in  STDXOGIC ;  —  bus  clock 

in  STD  .LOGIC; 
in  STD  .LOGIC; 

out  STD  .LOGIC  .VECTOR  (4 -  1  downto  0); 
in  STD  .LOGIC  .VECTOR  (28-1  downto  0); 
in  STDXOGIC .VECTOR (3  downto  0); 
out  STD  .LOGIC  .VECTOR  (0  to  31) 


); 


end  GOLD.wrapper; 


architecture  Behavioral  of  GOLD.wrapper  is 


—  CONSTANTS 


integer  :  =  4; 
integer : =28 
integer  :  =  0; 


—  COMPONENTS 


component  BUFGMUX 

port(0  :  out  STD.ULOGIC; 

10  :  in  STD.ULOGIC; 

11  :  in  STD.ULOGIC; 
S  :  in  STD.ULOGIC 

); 

end  component ; 

component  matrix.power  is 


constant  Master.NumOfFreqTaps 
constant  Master.Width 
constant  offset 
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generic  ( Width 

integer  :=  16  ) ; 

Port(  reset 

i  n 

STD -LOGIC ; 

elk 

i  n 

STDXOGIC ; 

feedback 

i  n 

STDXOGIC.VECTOR 

( Width -1 

downto 

0) 

first 

i  n 

STDXOGIC ; 

indexer 

:  out 

STDXOGIC.VECTOR 

(7  downto 

0); 

col.out 

out 

STDXOGIC.VECTOR 

( Width -1 

downto 

0) 

); 

end  component  matrix.power  ; 


component  collect_transpose  is 


generic  ( Width 
Port(  freq.clk 

detect_FFT 
reset 
col 

indexer 
col _out 
have  .first 
matrix.out 
occur.count 
fini  shed 
occur.indexes 

); 

end  component  c o  1  lec t _ t r an s p o s e 


integer  :=  16); 

in  STD  .LOGIC ; 
in  STD -LOGIC ; 
in  STDXOGIC; 

in  STD_LOGIC .VECTOR  ( Width -1  downto  0); 
in  STD-LOGIC.VECTOR  (7  downto  0); 
out  STD_LOGIC -VECTOR  (Width-1  downto  0); 
out  STDXOGIC; 
out  MATRIX; 

out  STDXOGIC.VECTOR  (7  downto  0); 
out  STDXOGIC; 

out  STDXOGIC.VECTOR  (127  downto  0) 


component  matrix _reduc e _3  is 


generic  ( Width 
Port(  matrix.in 
start 
reset 
elk 

finished 
matrix.out 

); 

end  component  matrix  .reduce  _3 


integer  :=  16); 

in  MATRIX; 
i  n  STDXOGIC ; 
l  n  STDXOGIC ; 
l  n  STDXOGIC ; 
out  STDXOGIC; 
out  MATRIX 


component  matrix.solver  is 


generic  (NumOfFreqTaps 

integer  :=  5 ; 

Width 

integer  :=  16 
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reset 

:  in 

STD.LOGIC ; 

start 

:  i  n 

STD_LOGIC ; 

elk 

:  i  n 

STD.LOGIC ; 

inputs 

:  i  n 

MATRIX; 

feedback 

:  in 

STDXOGIC.VECTOR 

(Width-1 

downto 

0) 

finished 

:  out 

STDXOGIC ; 

pulse 

:  out 

STD.LOGIC ; 

force.reset 

:  out 

STD.LOGIC ; 

output 

:  buffer 

STDXOGICJVECTOR 

(Width-1 

downto 

0) 

taps 

:  out 

STD_LOGIC_VECTOR 

(Width-1 

downto 

0) 

); 

end  component  matrix.sol ver  ; 


component  pn.gen  is 

g  e  r  :  =  5 ; 
g  e  r  :  =  16); 

STD  _LOGIC ; 

STD  .LOGIC ; 

STD  .LOGIC ; 

STD  .LOGIC-VECTOR  ( Width -1  downto  0); 
STD_LOGIC .VECTOR  ( Width -1  downto  0); 
STD-LOGIC  .VECTOR  ( Width -1  downto  0) 

); 

end  component  pn.gen  ; 


generic  ( NumOfFreqTaps  :  inte 


Width  :  inte 

port  (elk  :  in 

ShiftEn  :  in 

pulse  :  in 

DatalN.vector  :  in 

feedback  :  in 

pn.out  :  out 


component  freq.tap  is 
generic  (NumOfFreqTaps 
Width 
port(  PN.seq 
taps 

freq  .out 

); 

end  component  freq.tap  ; 


integer  :=  5 ; 


integer  :=  16); 


in  STD  .LOGIC .  VECT  OR  (Width  -1  downto 
in  STD  .LOGIC  .VECTOR  (Width  -1  downto 
out  STD  .LOGIC-VECTOR  (NumOfFreqTaps  - 


0); 

0); 

1  downto  0) 


—  INTERCONNECT  Signals 

signal  system.reset  :  STD  .LOGIC ; 

— power 
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signal  po  wer_to_transpose_vector 
signal  power.dk 
signal  power  _index 

—  collect 

signal  transpose_have_first 
signal  transpose.to  .reduce  .matrix 
signal  transpose.occur.  count 
signal  transpose.col.out 
signal  transpose.finish 
— reduce 

signal  reduce.dk 

signal  reduce.to.solver.matrix 

signal  reduce.finish 

—  solver 

signal  sol  ver.to  .extender.matrix 
signal  solver.finish 
— extender 

signal  extender.to.unique.  matrix 
signal  extender.finish 
— unique 

signal  unique.dk 
signal  unique.to.PN.vector 
signal  unique.finish 
signal  unique.command.rst 
signal  unique.to.pn.pulse 
signal  unique.taps  .out 
— pn 

signal  pn.clk.sel 
signal  pn.dk 
signal  pn.seq.out 

—  counter 
signal  tO.counter 
signal  pn.counter 
constant  zeros 
signal  synced 
signal  reset.counter 


STD.LOGIC.VECTOR  ( Master.Width -1 
STD  .LOGIC ; 

STD JLOGIC .VECTOR  (7  downto  0); 

STD  .LOGIC ; 

MATRIX; 

STD_LOGIC_VECTOR  (7  downto  0); 
STD.LOGIC.VECTOR  ( Master.Width -1 
STD  .LOGIC ; 

STD  .LOGIC ; 

MATRIX; 

STD  .LOGIC ; 

MATRIX.sol ; 

STD  .LOGIC ; 

MATRIX.sol.ext ; 

STD  .LOGIC ; 

STD  .LOGIC ; 

STD_LOGIC_VECTOR  ( Master.Width -1 
STD  .LOGIC ; 

STD  .LOGIC ; 

STD  .LOGIC ; 

STD .LOGIC.VECTOR  (  Master.Width -1 

STD  .LOGIC ; 

STD  .LOGIC ; 

STD.LOGIC.VECTOR  ( Master.Width -1 

STD  .LOGIC.VECTOR  (31  downto  0); 
STD  JLOGIC  .VECTOR  (31  downto  0); 
STD  .LOGIC.VECTOR  (31  downto  0)  : 
STD.LOGIC ; 

STD.LOGIC.VECTOR  (0  to  7); 


BEGIN  —  architecture 


downto  0); 


downto  0); 


downto  0); 


downto  0); 


downto  0); 


=  (others  =>  ’O’); 
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instantiations 


BUFGMUXJNSTANCEJMAME  :  BUPGMUX 


port  map  ( 

o 

=> 

pn.clk.sel  , 

10 

=> 

FAST.CLK , 

11 

=> 

FREQ.CLK , 

s 

=> 

synced  ) ; 

inst_po wer  : 

matrix_power 

generic  map  (Width 

=> 

Master.Width ) 

Port  map  ( 

reset 

=> 

system.reset  , 

elk 

=> 

power.clk  , 

feedback 

=> 

Master.Feedback  , 

first 

=> 

transpose.have.first  , 

indexer 

=> 

power.index  , 

); 

col  .out 

=> 

power.to  .transpose  .vector 

inst.transpose  :  collect.transpose 

generic  map(Width 

=> 

Master.Width ) 

Port  map  ( 

freq  _clk 

=> 

FREQ.CLK, 

detect.FFT 

=> 

FFT.IN  , 

reset 

=> 

system.reset  ,  — async  reset 

col 

=> 

power.to.transpose.vector  , 

indexer 

=> 

power.index  , 

have  .first 

=> 

transpose.have.first  , 

matrix  .out 

=> 

transpose.to.reduce.matrix  , 

c  o  1  _  o  u  t 

=> 

transpose.col.out  , 

occur .count 

=> 

transpose.occur.count  , 

fini  shed 

=> 

transpose. finish  , 

); 

occur.indexes 

=> 

OPEN  —  debug.transpose.index 

inst.reduce  : 

matrix.reduce 

.3 

generic  map  (Width 

=> 

Master.Width ) 

Port  map  ( 

matrix.in 

=> 

transpose.to.reduce.matrix  , 

start 

=> 

transpose.finish  , 

reset 

=> 

system.reset  , 

elk 

=> 

reduce.dk  , 
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finished 

=> 

reduce.finish  , 

); 

matrix.out 

=> 

reduce_to_solver_matrix 

inst.solver  : 

matrix.solver 

generic  map(NumOfFreqTaps 

=> 

Master.NumOfFreqTaps  , 

Width 

=> 

Master_Width ) 

Port  map  ( 

reset 

=> 

system.reset  , 

start 

=> 

reduce.finish  , 

elk 

=> 

FAST_CLK , 

inputs 

=> 

reduce_to_solver_matrix 

finished 

=> 

sol ver .finish  , 

output 

=> 

unique.to.PN.vector  , 

feedback 

=> 

Master.Feedback  , 

pulse 

=> 

unique.to.pn.pulse  , 

force.reset 

=> 

unique.command.rst  , 

); 

taps 

=> 

unique  .taps  .out 

inst_pn_gen  : 

pn.gen 

generic  map(NumOfFreqTaps 

=> 

Master.NumOfFreqTaps  , 

Width 

=> 

Master.Width ) 

port  map  ( 

elk 

=> 

pn.clk.sel  , 

ShiftEn 

=> 

solver .finish  , 

pulse 

=> 

unique.to.pn.pulse  , 

DatalN.vector 

=> 

unique.to.PN.vector  , 

feedback 

=> 

Master.Feedback  , 

); 

pn.out 

=> 

pn.seq.out 

inst.freq  .tap  :  freq.tap 

generic  map(NumOfFreqTaps 

=> 

Master.NumOfFreqTaps  , 

Width 

=> 

Master.Width ) 

port  map  ( 

PN.seq 

=> 

pn.seq.out  , 

taps 

=> 

unique  .taps  .out  , 

freq  .out 

=> 

FREQ.OUT 

); 


—  Processes 
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clks.since  .tOproc  :  process  (power.clk,  sy  stem.reset ) - counter  for  matrix  multiplier 

begin 

if  system.reset  =  *1*  then 
tO_counter  <=( others  =  >’ O’); 
elsif  (  rising-edge  (  power.clk  ))  then 
if  transpose_have_first  =  ’1’  then 

tO_counter<=std_logic_vector(  unsigned  (tO_counter)  +  l); 
end  if  ; 
end  if  ; 
end  process ; 

clks_since_ANSproc  :  process  (pn_clk_sel  ,  system.reset)  — counter  for  PN.seq  catchup 
begin 

if  system_reset  =’l’  then 

pn .counter  <=( others  =  >’ O’); 
elsif  (rising-edge  (  pn_clk_sel  ))  then 
if  (  s o  1  v e r _f i n i s h  =  ’  1  ’ )  then 

pn.counter  <=  std_logic_vector(unsigned(pn_counter)  +  l); 
end  if  ; 
end  if  ; 
end  process ; 

determine.syncproc:  process  (pn.counter,  tO.counter,  catchup_offset)  — COMPARTTOR 
begin 

if  pn_ counter  =  zeros  then 
synced  <=  ’ 0  ’ ; 

elsif  (unsigned(  tO  .counter  )<=  unsigned  (pn_counter)+unsigned(catchup_offset))then 
synced  <=  ’  1  ’ ; 
else 

synced  <=  ’ 0  ’ ; 

—  consider  adding  option 

—  if  gone  to  far 
end  if  ; 

end  process ; 

determine.resetproc  :  process  (  unique_command_rst  ,  ASYNC_RST) 
begin 

if  ASYNC.RST  =  ’1’  then 

reset_counter  <=  (others  =>  ’O’); 
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elsif  rising.edge  ( unique_command_rst )  then 

reset.counter  <=  std_logic_vector(unsigned(reset_counter)+l); 
end  if  ; 
end  process ; 


power.clk 
reduce_clk 
unique  _c  lk 
sy  stem.reset 


<=  FREQ.CLK ; 
<=  FAST.CLK; 
<=  FAST.CLK; 
<=  ASYNC_RST 


synced .out (0 

to 

3) 

<  = 

synced.out (4 

to 

7) 

<  = 

synced.out (8 

to 

15) 

<  = 

synced  .out (16 

to 

23) 

<  = 

synced.out (24 

to 

27) 

<  = 

synced.out (28 

to 

31) 

<  = 

synced  &  ’O’  &  ’O’  &  ’O’; 

(others  =>  ’O’); 
reset.counter ; 
transpose.occur.count ; 

’O’  &  ’O’  &’0’  &  ’O’; 

sol  ver.finish&reduce.finish&transpose  .finish&transpose.have  .first  ; 


end  Behavioral  ; 


C.2  Block  1:  Matrix  power  multiplication 

library  IEEE; 

use  IEEE.  STD_LOGIC.il 64. ALL; 

use  ieee  .  numeric.std  .  all  ; 

—  use  ieee . reduce.pkg .  all  ; 

— USE  IEEE  .  std.logic.arith  .  ALL ; 

— USE  IEEE  .  std.logic.unsigned  .  ALL ; 

—  library  mylibs.v  1  _00_a  ; 

—  use  mylibs.vl  _00_a  .  my  .package  .  all  ;  — ccm 
use  work  .  my  .package  .  a  1 1  ;  — ccm 

— program  to  reduce  a  16x16  binary  matrix  to  row  echelon 

entity  matrix.power  is 

generic  ( Width  :  integer  :=  16  ); 

Port  (  reset  :  in  STD  .LOGIC; 

elk  :  in  STD  .LOGIC ; 

feedback:  in  STD_LOGIC_VECTOR  (Width-1  downto  0); 
first:  in  STD  .LOGIC  ; 

indexer  :  out  STD_LOGIC_VECTOR  (7  downto  0); 
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col.out  :  out  STD_LOGIC_VECTOR  (Width-1  downto  0) 

); 

end  matrix_power  ; 


architecture  Behavioral  of  matrix.power  is 

—  type  MATRIX  is  array(15  downto  0)  of  STD_LOGIC_VECTOR  (15  downto  0); 

—  constant  s_shift_mat  :  subMATRIX  :=  ((”000000000000000”),  —row  15 

—  ("100000000000000”),  —row  14 

—  ("010000000000000”),  —row  13 

—  ("001000000000000”),  — row  12 

—  ("000100000000000”),  —row  11 

—  ("000010000000000”),  —row  10 

—  ("000001000000000”),  — row  9 

—  ("000000100000000”),  —row  8 

—  ("000000010000000”),  —row  7 

—  ("000000001000000”),  —row  6 

—  ("000000000100000”),  —row  5 

—  ("000000000010000”),  — row  4 

—  ("000000000001000”),  —row  3 

—  ("000000000000100”),  —row  2 

—  ("000000000000010"),  —row  1 

—  ("000000000000001”)  );  —row  0 


signal  shift_mat  :  MATRIX  :=  (others  =>  (others  =>  '0’));  — :  =  (("0000000000000000”) ,  —row  15 


(”  1000000000000000”), 

— row 

14 

("0100000000000000”), 

— row 

13 

(”0010000000000000”), 

— row 

12 

(”0001000000000000”), 

— row 

11 

("0000100000000000”), 

— row 

10 

("0000010000000000”), 

— row 

9 

("0000001000000000”), 

— row 

8 

("0000000100000000”), 

— row 

7 

("0000000010000000”), 

— row 

6 

("0000000001000000”), 

— row 

5 

("0000000000100000”), 

— row 

4 

("0000000000010000”), 

— row 

3 

("0000000000001000”), 

— row 

2 

("0000000000000100”), 

— row 

1 

("0000000000000010”) 

) ;  — row  0 
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signal  mat_int  :  MATRIX:  =  (others  =>  (others  =>  ’0’)); 


=  ((”0000000000000000”) ,  —row  15 


(”  1000000000000000”), 

— row 

14 

(”0100000000000000”), 

— row 

13 

(”0010000000000000”), 

— row 

12 

(”0001000000000000”), 

— row 

11 

(”0000100000000000”), 

— row 

10 

(”0000010000000000”), 

— row 

9 

(”0000001000000000”), 

— row 

8 

(”0000000100000000”), 

— row 

7 

(”0000000010000000”), 

— row 

6 

(”0000000001000000”), 

— row 

5 

(”0000000000100000”), 

— row 

4 

(”0000000000010000”), 

— row 

3 

(”0000000000001000”), 

— row 

2 

(”0000000000000100”), 

,  — row 

1 

(”0000000000000010”) 

) ;  — row 

STDXOGIC.VECTOR  (7 

downto 

0) 

begin 

process ( elk , reset  ,  feedback  )  is 

variable  temp.row  :  std _1  ogic .vector  (Width-1  downto  0); 
variable  temp_row2  :  std.logic  .vector  (Width-1  downto  0); 

variable  and.int  :  std.logic.vector  (Width-1  downto  0); 
variable  xor.bit  :  std.logic 


begin 

if  reset  =  *  1 ’  then 

for  i  in  0  to  Width-1  loop  —  for  each  row 

—  shift.mat  ( i)<=  s.shift.mat  ( i )  &  feedback(i); 


temp.ro w  :=  (others  =>  ’O’);  — set  all  to  zero 
temp.row(O)  :=  feedback(i);  — set  last  col  to  feedback 
if  i  /=  Width  -  1  then 

temp  .row  ( i  + 1 )  :=  ’1’;  — for  all  but  first  row,  create  ide 

end  if  ; 

shift  .mat  ( i)<=  temp.row  ; 


tity  matirx 
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temp_row2  :=  (others  =>  ’O’);  — set  all  to  zero 
temp_row2(i)  :=  *1’; 

mat.int  (i)  <=  temp_row2  ; 

end  loop ; 

—  col_out  <=  (others  =>  ’O’); 
indexer  <=  (others  =  >’0’); 
elsif  rising.edge  (  elk )  then 
if  (first  =  ’1’)  then 

for  i  in  Width-1  downto  0  loop  — rows 
for  j  in  Width-1  downto  0  loop  — cols 
for  h  in  Width-1  downto  0  loop 

and_int(h):=  (  mat_int  ( i  )  ( h )  and  shift  _mat  (h )( j  )) ; 
end  loop ; 


xor.bit  :  =  ’O’; 

for  k  in  Width-1  downto  0  loop 

xor_bit:=  xor.bit  xor  and_int(k); 
end  loop ; 

mat.int  ( i  )( j  )<=  xor.bit  ; 


—  mat_int  ( i  )( j  )  <  =  ((mat_int  ( i  )( 1  5)  and  shift.mat  ( 1  5)(  j  )) 


—  xor 

(  mat_int  ( i 

)(14) 

and 

shift_mat  ( 1 4 ) ( j  )) 

—  xor 

(  mat.int  ( i 

)( 1 3) 

and 

shift_mat(13)(j)) 

—  xor 

(  mat.int  ( i 

)( 12) 

and 

shif t .mat  (1  2) ( j  )) 

—  xor 

(  mat.int  ( i 

)(11) 

and 

s  hift  _mat  (1  l)(j  )) 

—  xor 

(  mat.int  ( i 

)( 1 0) 

and 

shift_mat(10)(j)) 

—  xor 

(  mat.int  ( i 

)( 

9) 

and 

shif t .mat  ( 

9)(j  )) 

—  xor 

(  mat.int  ( i 

)( 

8) 

and 

shif t .mat  ( 

8 ) ( j  )) 

—  xor 

(  mat.int  ( i 

)( 

7) 

and 

shif t .mat  ( 

7)(j )) 

—  xor 

(  mat.int  ( i 

)( 

6) 

and 

shif t .mat  ( 

6)(j )) 

—  xor 

(  mat.int  (  i 

)( 

5) 

and 

shif t .mat  ( 

5)(j )) 

—  xor 

(  mat.int  ( i 

)( 

4) 

and 

shif t .mat  ( 

4) ( j  )) 

—  xor 

(  mat.int  ( i 

)( 

3) 

and 

shif t .mat  ( 

3 ) ( j  )) 

—  xor 

(  mat.int  (  i 

)( 

2) 

and 

shif t .mat  ( 

2 ) ( j  )) 

—  xor 

(  mat.int  ( i 

)( 

1) 

and 

shif t .mat  ( 

1 )( j  )) 

—  xor 

(  mat.int  ( i 

)( 

0) 

and 

shif t .mat  ( 

0)(j  )) 
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end  loop ; 


end  loop ; 

indexer  <=  std_logic_vector(unsigned(indexer_i)  +  1); 
indexer.i  <=  std_logic_vector(unsigned(indexer_i)  +  1); 
end  if  ; 
end  if  ; 

—  finished  <=  ’  1  ’ ; 
end  process ; 

get.col  :  for  k  in  Width-1  downto  0  generate 
col_out(k)<=mat_int(k)(  Width  -  1 ); 
end  generate ; 

—  col  _out  <=mat_int(15)(15)&mat_int(14)(15)&mat_int(13)(15)&mat_int(12)(15)&mat_int(ll)(15)&mat_int(10)(15)& 

end  Behavioral  ; 

C.3  Block  2:  Collection  and  transposition 

library  IEEE; 

use  IEEE.  STD _LOGIC_l  164. ALL; 
use  ieee  .  numeric.std  .  all  ; 

— USE  IEEE  .  std_logic_arith  .  ALL ; 

— USE  IEEE  .  std_logic_unsigned  .  ALL ; 

—  library  mylibs_v  1  _00_a  ; 

—  use  mylibs_vl  _00_a  .  my.package  .  all  ;  — ccm 
use  work  .  my  .package  .  a  1 1  ;  — ccm 

—  collects  ’Width’  occurrences  ,  combines  to  create  a  matrix  and  transposes  matrix  for  output 

entity  collect.tr  anspose  is 

generic  ( Width  :  integer  :=  16); 

Port  (  freq.clk:  in  STD  .LOGIC; 
detect.FFT  :  in  STD.LOGIC ; 
reset:  in  STD.LOGIC; 

col  :  in  STD  .LOGIC-VECTOR  ( Width -1  downto  0); 
indexer  :  in  STD_LOGIC_VECTOR  (7  downto  0); 
have.first:  out  STD.LOGIC ; 
matrix.out  out  MATRIX; 

occur.count  :  out  STD  .LOGIC-VECTOR  (7  downto  0); 
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finished  :  out  STD  .LOGIC; 


—  first.col  :  out  STD_LOGIC_VECTOR  (Width-1  downto  0); 

occur.indexes  :  buffer  STD  .LOGIC-VECTOR  (127  downto  0);  — 16*  8  bit  index 
col.out  :  out  STD  .LOGIC-VECTOR  (Width-1  downto  0) 

); 

end  collect-transpose  ; 

architecture  Behavioral  of  collect-transpose  is 

—  type  MATRIX  is  array  (15  downto  0)  of  STD.LOGIC  .VECTOR  (15  downto  0); 

signal  c.state  :  integer  range  0  to  Width  +  1  :=  0;  — std.logic  .vector  (3  downto  0)  :=  ”0000”; 

—  signal  occur.indexes  _i  :  STDXOGIC.VECTOR  (127  downto  0); 
begin 

process( reset,  freq.clk)  is 
begin 

if  reset  =  ’l’  then 

have  .first  <=  ’O’; 
finished  <=  ’0  ’ ; 
c  .state  <=  0; 

matrix.out  <=  (others  =>  (others  =>  ’0’)); 
occur.indexes  <=  (others  =>  ’O’); 

elsif  falling.edge  (freq.clk)  then 
if  detect.FFT  =  *1*  then 
if  c.state  =  0  then 

— ignore  first  occurrence 
c.state  <=  c.state  +  1; 
have  .first  <=  ’  1  ’ ; 
col.out  <=  col ; 

—  first.col  <=  col ; 

elsif  (c.state  <  Width  +  1)  then 

matrix.out  (  c  .state  - 1)  <=  not  (  col  ( Width  -  1 ))  &  col(Width-2  downto  0); 
c.state  <=  c.state  +  1; 
col.out  <=  col  ; 

occur.indexes  <=  occur  .indexes  ( 1 1 9  downto  0)  &  indexer;  — will  shift  all  collections  into  the  vecto 

—  occur.indexes.i  <=  occur.indexes.i  (1 19  downto  0)  &  indexer; 
if(c_state  =  Width)  then 

finished  <=  ’  1  ’ ; 
end  if  ; 
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else 


finished  <=  ’1’;  — all  have  been  filled 
end  if  ; 
end  if  ; 
end  if  ; 

end  process ; 


occur_count  <=  std _logic .vector ( to_unsigned  (  c_state  ,8)); 
end  Behavioral  ; 

C.4  Block  3:  Matrix  reduction 

library  IEEE; 

use  IEEE.  STD _LOGIC_l  164. ALL; 
use  ieee  .  numeric.std  .  all  ; 

—  library  mylibs.v  1  _00_a  ; 

—  use  mylibs.v  1  _00_a  .  my.package  .  a  1 1  ;  — ccm 
use  work  .  my  .package  .  a  1 1  ;  — ccm 

entity  matrix  .reduce  _3  is 

generic  ( Width  :  integer  :=  16); 

Port  (  matrix.in  :  in  MATRIX; 

start  :  in  STD  .LOGIC ; 
reset  :  in  STD  .LOGIC ; 

elk  :  in  STD  .LOGIC ; 
finished  :  out  std.logic  ; 
matrix.out  out  MATRIX 
); 

end  matrix_reduce_3  ; 

architecture  Behavioral  of  matrix_reduce_3  is 

signal  stage  :  integer  range  0  to  6; 

signal  col.case  ,  row.case  ,  first.one  :  integer  range  0  to  width; 
signal  flag  :  std.logic; 
signal  mat.int  :  MATRIX; 

signal  temp.row  :  std  .logic  .vector  (  width -1  downto  0); 

begin 
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process ( elk )  i s 

variable  var.vector  :  s  td  _1  o  g  i  c  _v  e  c  to  r  (  width -1  downto  0); 
variable  var_vector2  :  std_logic  .vector  (  width -1  downto  0); 
variable  var.swap  :  s td _  1  o gi c _v ec to r  ( width -1  downto  0); 
begin 

if  rising.edge  (  elk  )  then 
if  reset  =  ’  1 ’  then 

—  m at _i n t  <=  m  at r i  x  _i  n  ; 
col.case  <=0; 

stage  <=0; 
flag  <=  ’O’; 
row.case  <=width  ; 
finished  <=  ’O’; 
first.one  <=  width-1; 

elsif  (start  =’l’)  then  — repeat  width  times:  2n~2  +  2n 

—  stage  1  -  find  first  one,  record  row  number  and  vector  — width  iterations 

—  stage  2  —  go  through  all  vectors  to  XOR  if  it  has  a  one  (ignore  the  selected  vector)  — width  ite 

—  stage  3  -  row  swap  —  1  iteration 

—  stage  4  -  row  elements  rotate  left  —  1  iteration 

—  stage  5  — 

—  stage  6  -  hold  stage  ,  dont  do  anything  —  requires  reset 
i f  (  stage  =0)  then 

mat.int  <=matrix  _in  ;  — load  initial  values 

—  col.case  <=(); 
stage  <  =  1 ; 

—  flag  <=  ’0  ’ ; 

—  row.case <=width  ; 

—  finished  <=  ’O’; 
col.case  <=0; 
flag  <=  ’O’; 
row.case  <=width  ; 
finished  <=  ’O’; 
first.one  <=  width-1; 

elsif  (stage  =  l  or  stage  =  2)  then 
i f  ( row.case  >0  and  stage  =  1)  then 

if  flag  =’0’  and  row_case>  col.case  then 
if  mat.int  (  width  -  1 )( width  - 1)  =  ’1’  then 
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temp.row  <=  mat.int  ( width  -  1 ); 
first.one  <=  row_case-l; 
flag<=’l’;  — found  a  ’one’ 
end  if  ; 
end  if  ; 

var_vector:=mat_int(  width  -  1 ) ; 
row.case <=row_case  -1; 
e  1  s  i  f  (  row.case  >0  and  stage  =  2)  then 

if(  (row_case-l  /=  first.one)  and  (  mat.int  (  width  -  1 )( width  - 1)  =  ’1’)  )  then 
var_vector:=  mat_int  ( width  —  1)  xor  temp_row  ; 

else 

var.vector  :=  mat.int  ( width  -  1 ) ; 
end  if  ; 

row.case  <=row_case  —1; 
end  if  ; 

i  f  (  row.case  >0)  then 

mat.int  (  width —1  downto  1)  <=  mat.int  (  width -2  downto  0); 
mat_int(0)<=  var.vector; 
else  — (row_case=0)  then 

if  flag=  ’0’  then  — if  a  one  was  never  found 
temp.row  <=  (others=>  ’O’); 
end  if  ; 

flag  <=  ’O’; 
row.case  <=width  ; 
stage  <=  stage  +  1 ; 

—  row.case  <=  width; 
end  if  ; 

elsif  stage  =  3  then 

—  swap  top  row  and  first.one 
if(first_one  /=  Width-1)  then 
var.swap  :=  mat.int  (  width  -  1 ) ; 
mat.int  (  width  -  1)  <=  mat.int  (  first.one  ) ; 
mat_int(  first.one)  <=  var.swap; 
end  if  ; 
stage  <=  4; 

elsif  stage  =  4  then 

var_vector2:  =  mat.int  (  width  -  1); 
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mat.int  ( width -1  downto  1)  <=  mat.int  ( width -2  downto  0); 
mat_int(0)<=  var_vector2  ; 
first_one  <=  width— 1; 
stage  <=  5 ; 

elsif  stage  =  5  then 

—  rotate  left  each  row  by  one  element 
for  i  in  width-1  downto  0  loop 

mat.int  ( i  )(  width -1  downto  1)  <=  mat.int  ( i  )(  width -2  downto  0); 
mat_int  ( i  )(0)  <=  mat _int  ( i  )(  width  -  1 ) ; 
end  loop ; 

— row.case  <=  width; 
if  col.case  <  width-1  then 
col_case<=  col_case+l; 
stage  <=  1; 

else  — we  have  rotated  through  each  element  in  the  rows 
stage  <=  6; 

end  if  ; 

elsif  stage =6  then 

matrix_out<=mat_int  ; 
finished  <=  ’  1  ’ ; 
end  if  ; 
end  if  ; 
end  if  ; 

end  process  ; 
end  Behavioral  ; 

C.5  Blocks  4  and  5:  Solution  solver 

library  IEEE; 

use  IEEE.  STD _LOGIC_l  164. ALL; 
use  ieee  .  numeric.std  .  all  ; 

— USE  IEEE  .  std_logic_arith  . ALL ; 

— USE  IEEE  .  std_logic_unsigned  .  ALL ; 

—  library  mylibs.v  1  _00_a  ; 

—  use  mylibs_vl_00_a.my_package.all;  — ccm 
use  work  .  my  .package  .  a  1 1  ;  — ccm 

—  use  work.  std_logic_l  1  64_additions  .  all  ; 
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— program  to  reduce  a  16x16  binary  matrix  to  row  echelon 


entity  matrix  .solver  is 

generic  ( NumOfFreqTaps  :  integer  :=  5; 

Width  :  integer  :=  16 

— Max.Combos  :  integer  :=  31  —  2,vNumOfFreqTaps  -1 

); 

Port  (  reset  :  in  STD  .LOGIC; 

start  in  STD  .LOGIC ; 
elk  :  in  STDXOGIC; 
inputs  :  in  MATRIX; 

—  inputs  in  STDXOGIC.VECTOR  (255  downto  0); 

—  finished  :  out  STDXOGIC 

—  outputs  :  out  MATRIX.sol  — 31  sets  of  16  bit  solution  space 

—  start  :  in  STD  .LOGIC ;  — 

—  elk  :  in  STD  .LOGIC;  — 

—  inputs  in  MATRIX.sol;  — 

feedback:  in  STDXOGIC.VECTOR  (Width-1  downto  0); 
finished  :  out  STD.LOGIC ;  — 
pulse  :  out  STDXOGIC ; 

—  reset  :  in  STDXOGIC;  — 
force.reset:  out  STDXOGIC; 

output  :  buffer  STDXOGIC.VECTOR  ( Width -1  downto  0); 
taps  :  out  STDXOGIC.VECTOR  ( Width -1  downto  0) 


); 

end  matrix  .sol  ver  ; 

architecture  Behavioral  of  matrix.solver  is 

—  type  MATRIX  is  array  (15  downto  0)  of  STDXOGIC.VECTOR  (15  downto  0); 

—  type  MATRIX2  is  array  (31  downto  1)  of  STDXOGIC.VECTOR  (15  downto  0);  — removed  zero  vector  31-1 

type  FSM.States  is  (SO  ,  SI  ,  S2  ,  S3  ,  S4a  ,  S4  ,  S5  ,  S6  ,  S7a  ,  S7  ,  S8a  ,  S8  ,  S9  ) ; 

signal  stage:  FSM.States  :=  SO; 

signal  row.case  :  integer  range  0  to  width  :=  width; 

signal  temp.row  :  STDXOGIC.VECTOR ( Width -1  downto  0)  :=  (others  =>’0’); 

—  signal  sol.mask  :  STDXOGIC.VECTOR ( Width -1  downto  0)  :=  (others  =>’0’);  — mask  to  show  that  these  are  set 
signal  var.loc  :  STDXOGIC.VECTOR ( Width -1  downto  0)  :=  (others  =>’0’);  — mash  to  show  these  are  the  variable 
signal  var.values  :  STDXOGIC.VECTOR  ( NumOfFreqTaps -1  downto  0)  :=  (others  =  >  *  0  * ) ; 

—  type  sum.type  is  array  (Width-1  downto  0)  of  unsigned(4  downto  0); 
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—  signal  sum  :  sum.type  :=  (others=>  (others=>  ’0’));  — set  to  max  number  of  256  — needs  enough  bits  to  r 


—  signal  matrix.in  :  MATRIX  :=  (others  =>  (others=>  ’0’)); 


signal  row.state  :  integer  range  0  to  2**NumOfFreqTaps  :=  0; 
signal  shift_state:  integer  range  0  to  Width  :=  0; 

signal  temp.small  :  STD_LOGIC_VECTOR  (Width-1  downto  0)  :=  ( others  =  > ’0 ’); 
signal  temp  :  STD_LOGIC_VECTOR  ( Width -1  downto  0)  :=  (others  =  >’0’); 

signal  occur  :  STD_LOGIC_VECTOR  (2* *  NumOfFreqTaps  downto  1)  :=  (  others  =  > ’0 ’);  — had  to  add  an  extra 
signal  count:  integer  range  0  to  NumOfFreqTaps  :=  0; 

—  signal  stage:  integer  range  0  to  4; 

signal  p  o  s  i  t  i  o  n  :  STD  _LOGIC_VECTOR  ( Width -1  downto  0)  :=  (others  =  >’0’); 
signal  index:  integer  range  0  to  2**NumOfFreqTaps-l  :=  0; 

signal  comp_index:  integer  range  1  to  2**NumOfFreqTaps  - 1 ; 
signal  comp_temp:  STD -LOGIC-VECTOR  ( Width -1  downto  0); 
signal  comp_ans  :  STD_LOGIC ; 
signal  comp_occur:  STD -LOGIC ; 

constant  zeros  :  STD_LOGIC_VECTOR  (2**NumOfFreqTaps-l  downto  1)  :=  (others  =>  ’O’); 

—  constant  zeros_width  :  STD_LOGIC_VECTOR  (Width-1  downto  0)  :=  (others  =>  ’O’); 

constant  zeros.tap  :  STD -LOGIC-VECTOR  (NumOfFreqTaps-1  downto  0)  :=  (others  =>  ’O’); 
constant  zeros_width  :  STD_LOGIC_VECTOR  (Width-1  downto  0)  :=  (others  =>  ’O’); 

signal  we:  STD -LOGIC  :=’0’; 

signal  addr :  integer  range  0  to  2**NumOfFreqTaps-l  :=  2**NumOfFreqTaps  - 1 ; 
signal  do:  STD_LOGIC_VECTOR  (Width-1  downto  0)  :=  (others  =>  ’O’); 
signal  di  :  STD.LOGIC_VECTOR  (Width-1  downto  0)  :=  (others  =>  ’O’); 
constant  en:  STD-LOGIC  :=’l’; 
signal  RAM  :  MATRIX.sol ; 
attribute  ram_style  :  string  ; 

attribute  ram.style  of  RAM  :  signal  is  ’’block”; 

begin 

process ( elk )  i s 

—  variable  tracking  :  STD_LOGIC_VECTOR( Width -1  downto  0)  :=  (others  =>’0’);  — shows  during  loop  if  the 
variable  count.n  :  integer  range  0  to  Width:  =  0; 

variable  sol_vec:  STD_LOGIC_VECTOR(  Width -1  downto  0)  :=  (others  =>’0’); 


front 


valui 


173 


variable  matrix_out_bit  :  std.logic  :=’l’; 
begin 

if  rising_edge  (  elk  )  then 
if  reset  =  ’ 1  *  then 
finished  <=  ’O’; 
stage  <=  SO; 
row_case  <=  Width; 

force.reset  <=’0’;  — creates  the  reset  pulse  through  the  system 
pulse  <=  ’O’; 

—  finished  <=  ’0  ’ ; 
taps  <=(  other s  =  >  ’ 0  ’ ); 
output  <=(  others  =  >  ’0  ’); 

—  stage  <=  0; 

elsif  start  =  ’  1 ’  then 

case  stage  is 
when  SO  => 

—  if  stage  =  0  then 

—  tracking  <=  (others  =>’0’); 

—  sol_mask  <=  (others  =>’0’); 

var.loc  <=  (others  =>’0’); 
matrix_out_bit  :=  ’1’; 

row_case  <=  Width; 

stage  <=  SI ; 

when  SI  => 

—  elsif  stage  =  1  then  — determines  if  sum  represents  a  known  value 
if(row_case  >  0)  then 

if  ( inputs  (  row.case -1)  =  zeros.width)  then 
var.loc  (  row.case  - 1)  <=  ’1’; 
end  if  ; 

row.case  <=  row.case  -  1; 
else 

stage  <=  S2 ; 

row.case  <=  Width; 

var.values  <=  (others  =>  ’1’); 

—  tracking  <=  sol.mask  or  var.loc  ; 
end  if  ; 


variable 
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when  S2  => 


—  elsif  stage  =  2  then 

if  ( v a r .values  /=  zeros.tap)  then  —  loops  over  32 

sol.vec  :=  (others  =>  ’O’); 
count.n  :=  0; 

for  x  in  Width-1  downto  0  loop 
if  var_loc (x)= ’ 1 ’  then 

sol_vec(x)  :=  var_values  (NumOfFreqTaps—  l-count_n  ) 
count.n  :=  count.n  +  1; 
end  if  ; 
end  loop  ; 

temp.row  <=  sol.vec  ; 
stage  <=  S3; 
row.case  <=  0; 
we  <  =  ’  0  ’ ; 
else 

stage  <=  S4a ; 
we  <  =  ’  0  ’ ; 

addr  <=2**NumOfFreqTaps  -  1 ; 
end  if  ; 

when  S3  => 

— elsif  stage  =  3  then 

if(row_case  <  Width  )  then 
—  loop  over  i  0:15 

sol.vec  :=  temp.row  and  inputs  ( row.case )  ; 

matrix.out.bit  :  =  ’0 

for  k  in  Width-1  downto  0  loop 

matrix.out.bit  :=  matrix.out.bit  xor  sol.vec(k); 
end  loop ; 

i  f  ( inputs  (  row.case  )  /=  zeros.width)  then 
temp.row  (  row_case)<=  matrix.out.bit  ; 
end  if  ; 
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row.case  <=  row.case  +  1; 
else 

stage  <=  S2 ; 

— RAM(  to.integer  (  unsigned  (  var.values  )))  <=  temp.row;  — possibly  write  to  bram 
ad  dr  <=  to  .integer  (unsigned(var_values  )); 
di  <=temp_row  ; 
we<=  ’  1  ’ ; 

var.values  <=  std.logic  .vector  (  unsigned  (  var.values  )  -  1); 

—  row.case  <=  Width; 
end  if  ; 

when  S4a=>  stage  <=  S4 ;  — cause  extra  cycle  for  RAM  read 

when  S4  => 

—  elsif  stage=4+0  then 

—  if  stage  =  0  then 

—  stepO  ; 

shift.state  <=  Width -1; 
row.state  <=  2**NumOfFreqTaps  - 1 ; 

—  load  a  extended  row 

temp.small  <=  do;  — RAM(2* * NumOfFreqTaps  -  1 ) ; 

position  <=  (others  =>  ’O’); 

occur  <=  (others  =>  ’O’); 

count  <=  0; 

stage  <=  S5 ; 

index  <=  2**NumOfFreqTaps  -  1 ;  — 31 


when  S5  => 

— elsif  stage  =  4+1  then 

—  s  t  e  p  1 

—  compare  temp  to  all  other  short 
if(index>0)  then  — repeat  through 

comp.temp  <=  temp.small  ;  — reg 

—  comp.index  <=  index  ; 
addr  <=index ; 
index<=index  -1; 

else 

stage  <=  S6 ; 

—  addr <=row .state  ; 


solutions  ; 

all 

value 

—  reg  input  index  to  compare  to 
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end  if  ; 

occur  ( index  + 1)  <=  comp.ans  ;  —  loads  value  from  last  compare 

when  S6  => 

— elsif  stage  =  4+2  then 

—  step2 

—  did  a  match  occur 

if  ( comp.occur  =  ’  1  ’)  then  — occur  (2**NumOfFreqTaps-l  downto  1)  /=  zeros)  then 
position  (shift.state)  <=  ’1’; 
count  <=  count  +  1; 
else 

position  (shift_state)  <=  ’O’; 
count  <=  count ; 
end  if  ; 

—  position  (  shift.state  -1)  <=  comp.occur; 

—  count  <=  count  +  to.integer  ( comp.occur  ) ; 

stage  <=  S7a; 
addr <=row_state  ; 

when  S7a  =>  stage  <=  S7 ;  —  cause  extra  cycle  for  RAM  read 
when  S7  => 

— elsif  stage  =  4+3  then 

—  s  t  e  p  3  —  control  section 

if  (count  =  NumOfFreqTaps )  then  — we  have  a  solution  ,  no  more  to  do 
—  done  !  ! ! 

output  <=  do;  — RAM(  row  .state  ) ; 
taps  <=  position  ; 
pulse  <=  ’  1  ’ ; 
stage  <=  S9 ; 

elsif  shift.state  >  0  then  — no  solution  yet,  still  have  more  shifts  available 
temp.small  <=  temp; 
shift.state  <=  shift.state  -1; 
occur  <=  (others  =>  ’O’); 
index  <=  2*  *  NumOfFreqTaps  -  1 ; 
stage  <=  S5  ; 
else 

stage <=  S8a; 
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if  row_state  >  1  then 


addr <=row_state  -1; 
end  if  ; 
end  if  ; 

when  S8a  =>  stage<=S8;  — cause  extra  cycle  for  RAM  read 
when  S8  => 

if  shift.state  =  0  and  row.state  >  1  then  — no  more  shifts  ,  but  other  rows 
temp.small  <=  do;  — RAM(  row  .state  -  1 ) ; 
shift_state  <=  Width-1; — reset  shift 
row_state<=  row_state— 1; 
position  <=  (others  =>  ’O’); 
occur  <=  (others  =>  ’O’); 
count  <=  0; 

index  <=  2**NumOfFreqTaps  -  1 ; 
stage  <=  S5 ; 

else  — no  more  rows 

— no  solution  found 
force. reset  <  =  ’  1  ’ ; 
stage  <=  SO; 
end  if  ; 

when  S9  => 

— elsif  stage  =  4+4  then 

if  (output  =  zeros.width)  then 
force  .reset  <=  ’  1  ’ ; 
stage  <=  SO; 
else 

—  step  4  — 
pulse  <=  ’O’; 
finished  <=  ’  1  ’ ; 
end  if  ; 
end  case ; 

end  if  ; 
end  if  ; 

end  process ; 

process  (elk) 
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begin 

if  elk  ’ event  and  elk  =  ’1’  then 
if  en  =  ’ 1 ’  then 
if  we  =  *  1 ’  then 
RAM(addr)  <=  di  ; 
end  if  ; 

do  <=  RAM(addr)  ; 
end  if  ; 
end  if  ; 
end  process  ; 


extend:  proces  s  ( temp_small )  is 

—  variable  extended  :  STD_LOGIC_VECTOR  (Width  downto  (0)) Width  - 1)  downto  (-  1  *(  Width  -  1 )))  :  = 

—  variable  adding  :  std.logic  .vector  (Width-1  downto  0)  :=  (  others  =  > ’0 ’); 

variable  add.bit:  std.logic  :=  ’O’; 

begin 

—  extended  :=  temp.small  &  ’O’; 

—  feedback  taps  on  3,5,7,11,13 

—  for  j  in  Width-2  downto  0  loop 

—  adding  :=  feedback  and  temp.small; 
add.bit  :=  ’O’; 

for  x  in  Width-1  downto  0  loop 

add_bit:=  add.bit  xor  (feedback(x)  and  temp.small  (x )) ; 
end  loop ; 

—  extended(O)  :=  add.bit; 

— end  loop ; 

temp  <=  temp.small  (Width-2  downto  0)  &  add.bit; 
end  process ; 

comp.ans  <=  ’1’  when  (comp.temp  =  do)  else  ’O’;  — RAM(  comp.index ))  else  ’O’; 
comp_occur<=  ’0’  when  occur  (2**NumOfFreqTaps-l  downto  1)  =  zeros  else  ’1’; 


end  Behavioral  ; 

C.6  Block  6:  PN  Sequencer 

— The  following  is  example  code  that  implements  two  LFSRs  which  can  be  used  as  part  of  pn  generators  . 
— The  number  of  taps  ,  tap  points  ,  and  LFSR  width  are  parameratizable  .  When  targetting  Xilinx  (Virtex) 
—  all  the  latest  synthesis  vendors  (Leonardo,  Synplicity  ,  and  FPGA  Express)  will  infer  the  shift 


( others 
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—  register  LUTS  (SRL16)  resulting  in  a  very  efficient  implementation. 


—  Control  signals  have  been  provided  to  allow  external  circuitry  to  control  such  things  as  filling 
-puncturing,  stalling  (augmentation),  etc. 

-Mike  Gulotta 
- 1 1/4/99 


—  Revised  3/17/00: 

Fixed  ’’commented”  block  diagram  to  match  polynomial  . 

—  Adapted  7/10/2013 

by  Capt  Curtis  Medve 

library  ieee  ; 

use  ieee  .  std.logic _  1  1  64  .  al  1  ; 
use  ieee  .  numeric.std  .  all  ; 

entity  pn.gen  is 

generic  ( NumOfFreqTaps  :  INTEGER  :=  5;  —  #  of  taps  for  I  channel  LFSR,  including  output  tap 


Width 

:  INTEGER  :=  16);  —  LFSR  length  (ie,  total  #  of  storage  elements) 

port  (  elk 

in  STD-LOGIC ; 

ShiftEn 

in  STD.LOGIC; 

pulse  in  STD_LOGIC ; 


DatalN.vector 

:  in  STD _LOGIC_VECTOR  ( Width -1  downto  0); 

feedback  : 

in  STD -LOGIC-VECTOR  ( Width -1  downto  0); 

pn.out 

:  out  STD-LOGIC _VECTOR(  Width -1  downto  0) 

) » 

end  pn.gen  ; 

architecture  rtl  of  pn.gen  is 

type  TapPoint Array _i  is  array  (NumOfFreqTaps-1  downto  0)  of  integer 

—  Parameratize  I  LFSR  taps.  (e.g.  I(x)  =  X**17  +  X**5  +  1) 

—  Plug  in  I  channel  tap  points  ,  including  output  tap  0. 


—  constant  Tap.i 

TapPointArray.i  :=  (13,11,9,5,3);  — relative  it  15:0  or  reverse  of  3,5,7,11,13 

signal  srl.i 

:  STD_LOGIC_VECTOR(  Width -1  downto  0);  —  shift  register. 

signal  par.fdbk.i 

:  STD-LOGIC_VECTOR(  Width -1  +  1  downto  0);  —  Parity  feedback. 

signal  lfsr.in.i 

:  STD-LOGIC ;  —  mux  o  u  t  p  u  t  . 

—  signal  start.flag  STD  .LOGIC  ; 
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I  Channel 


begin 


Shift_i  :  process  (  elk  ,  pulse  ,  DataIN  .vector  ) 
begin 

i f  pulse  =  ’  1  ’  then 

s r  1  _ i  <=  DatalN.vector  ; 

elsif  rising.edge  (  elk )  then 
if  ShiftEn  =  *1*  then 

s  r  1  _  i  <=  sr  1  _i  (Width-1  — 1  downto  0)&  lfsr_in_i; 
end  if  ; 
end  if  ; 
end  process ; 

par_fdbk_i(0)  <=  ’O’; 

fdbk.i  :  for  X  in  0  to  Width-1  generate  —  parity  generator 

par_fdbk_i  (X+l)  <=  p  ar  _f  dbk  _i  (X)  xor  (srl_i(X)  and  feedback  (X) ) ; 
end  generate  fdbk.i  ; 

—  lfsr_in_i  <=  Dataln.i  when  FillSel  =  ’1’  else  par  _f  dbk_i  ( par_fdbk_i  ’high); 
lfsr_in_i  <=  par.fdbk  _i  (Width  ) ; 

pn.out  <=  s r  1  _ i  ;  —  PN  I  channel  output. 


end  rtl ; 

C.7  Block  7:  Frequency  Tap 

library  ieee  ; 

use  ieee  .  std_logic_l  1  64  .  all  ; 
use  ieee  .  numeric.std  .  all  ; 

entitv  frea  tan  is 

—  #  of  freq  taps 

—  length  of  input  vector 

port(  PN.seq  :  in  std  .logic  .vector  (Width  -1  downto  0); 


generic  ( NumOfFreqTaps 
Width 


integer  :=  5 ; 
integer  :=  16); 
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taps 

freq.out 


in  std_logic_vector  (Width  -1  downto  0); 

out  std_logic_vector  ( NumOfFreqTaps  -  1  downto  0) 


); 

end  freq.tap  ; 

architecture  behavioral  of  freq.tap  is 
begin 

get.them  :  process  (PN.seq,  taps) 

variable  temp.output  :  std.logic  .vector  (NumOfFreqTaps  -  2  downto  0)  :  = 
begin 

for  i  in  Width-2  downto  0  loop 
if  taps ( i )=  ’  1 ’  then 

temp.output  :=  temp.output  (NumOfFreqTaps  -  3  downto  0)  &  PN.seq(i); 
end  if  ; 
end  loop  ; 

freq_out<=  PN.seq  ( Width  - 1)  &  temp.output; 
end  process ; 
end  behavioral  ; 


(  others  =  >  ’0  ’); 
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